What we've been shipping. Updated every friday.
Transferring a project moves its open usage too, so the previous owner stops paying for it.
When a project is transferred to a team, its open compute usage moves with it, so the previous owner stops being billed for a project they no longer own.
Root and wildcard custom domains on Cloudflare-proxied zones stop failing with error 1014.
Root and wildcard custom domains proxied through Cloudflare no longer fail with error 1014, with wildcard records pointing at a DNS-only target and root domains registered on the edge. Only custom domains actually attached to a project count toward your plan's limit, and detached domains are released from the edge.
Deploys clear the cache for every custom domain, so sites stop serving old HTML.
Deploys now purge every custom domain on a project, including domains you bought through Brimble and domains on Cloudflare-proxied zones, from both the Purge Cache button and the deploy itself. This stops sites, especially Next.js, from serving stale HTML that points at deleted assets.
A broad set of behind-the-scenes security enhancements to keep your apps and data safer.
We shipped a broad set of behind-the-scenes security enhancements across the platform this week to keep your apps and data safer.
A cleaner, full-width layout for charts and logs, with search and a persistent console.
Charts now run full width, stat and chart cards share a cleaner header-and-panel layout, and logs get a sticky, full-width table with a query search and field suggestions that replaces the old advanced filters. Run history is inline and click-to-expand with copyable output, and the console keeps your shell session as you move between project tabs, closing it after a few minutes away and warning you while a deployment is running.
More container images are accepted and framework detection makes fewer wrong guesses.
Images published as OCI indexes, including many from GitHub Container Registry, are now accepted instead of being rejected as invalid. Framework detection is also more precise: it only treats a project as Docker when there is a real Dockerfile, no longer mistakes Next.js or Bun apps for React based on package.json alone, and recognises Bun from its lockfile and packageManager field.
Get told before a database fills up and when a backup bucket is in the wrong region.
Brimble emails the database owner once when storage passes 95 percent full, and again only after it clears and fills up again, so the warning stays meaningful. When your backup bucket sits in a different region from its database the dashboard flags how far apart they are and links you straight to creating one in the recommended region.
Config files defined in brimble.toml now mount into plain Docker containers, not just buildpack apps.
Config files defined in brimble.toml now mount into plain Docker containers, not only buildpack apps, so your app reads them at the path you expect. Directory mount paths resolve correctly on deploy: a directory path is treated as the folder and the file is mounted inside it by name.
Edit environment variables in a proper editor that keeps values hidden until you look.
Environment variables get a dedicated editor with line numbers, a blur-to-reveal guard that keeps values hidden until you choose to look, toggles to switch between the list and raw formats, and saving through the unsaved-changes bar.
Give a worker its own cron command so one worker can run different scheduled jobs.
Worker projects can now run a specific command on a cron schedule instead of only their start command, so a single worker can run different scheduled jobs. Leaving the command empty falls back to the start command as before, and quotes in a cron command are preserved instead of being cut off.
See exactly where your spend goes with a full usage breakdown and downloadable reports.
A new usage page breaks spend down with a date-range picker, a spend summary, a daily cost chart, cost by product, and per-project detail, plus a cumulative chart that projects your bill for the chosen period. Ranges load in place with a skeleton, you can download the usage breakdown as a PDF for any range, and open invoices now let you pay or download their breakdown from a single invoice menu.
Turn a personal account into a team workspace without moving any of your resources.
A personal account can now become a team workspace in place, without moving any projects, databases or settings. Your resources stay exactly where they are, the owner is kept on projects and alert rules, and you can start the conversion straight from the billing modal.
Run MySQL with automatic failover behind a single writer endpoint that always points at the current primary.
You can now create high-availability MySQL databases backed by Group Replication. A single public writer endpoint always resolves to the current primary, with each member relaying to it through the mesh and a one-second primary check keeping the route current. Connection pooling is available on HA, running two pooled instances on separate nodes behind one public port, and the dashboard surfaces replication lag and a High Availability badge in the workbench header.
Restore a MySQL database to any minute in its recovery window, single-node or high-availability.
Point-in-time recovery now covers MySQL, both single-node and high-availability, alongside Postgres. Brimble archives your binary logs every minute and restores to any moment into a brand-new database, leaving the original untouched and using no extra compute while the restore runs. Recovery keeps its own daily base backup and is mutually exclusive with scheduled automatic backups, the available window is read from your own bucket and shown on the database timeline, and the overview page gives you the exact CLI command to run a restore. On supported databases it turns on and off by flipping a flag with no redeploy, and it is available on plans that include it with an upgrade prompt where it is not.
Sign in to Brimble through your own identity provider, with members provisioned and billed automatically.
Team SSO is now available, powered by WorkOS. Login gains a Sign in with SSO option, and team owners get an SSO section in Members settings with setup links to connect their provider, per-seat pricing shown up front, a default role applied to provisioned members, and a Require SSO toggle that forces everyone on the team to sign in through SSO, with a clear prompt shown to members when their team requires it. Directory Sync keeps membership in step with your directory through a webhook that adds and removes members as it changes, first-time SSO sign-in provisions the member automatically, and both SSO and Directory Sync appear as line items in your billing breakdown and usage page.
Billing, teams, config as code, domains, logs and object storage: smaller fixes across the platform.
build.dockerfile are built with that Dockerfile.brimble.toml are created correctly: engine names are matched regardless of case, missing credentials are generated, and the disk defaults to the 10 GB minimum when none is set.www is attached to a root domain, its DNS record is listed right next to the root's.If-None-Match: * on uploads, so an upload that shouldn't overwrite an existing object is rejected with 412 Precondition Failed.The old version of your app keeps serving while traffic moves to the new one, static sites are compressed and build faster, and visitors see a clear page when an app can't be reached.
No more error bursts after a redeploy. When a new version goes live, the previous one now keeps serving for 20 seconds while traffic moves over, instead of being shut down instantly. Requests that were still on their way to the old version, including form submissions and other POST requests, are answered instead of failing.
Compressed static sites. Static sites are now served with zstd or gzip compression, depending on what the visitor's browser supports. Files that are already compressed, like images, fonts and video, are left as they are.
Faster static builds. Static sites build on dedicated build machines in your project's region, and publishing the finished site is quicker.
Clear error pages. If your app can't be reached because it's starting, restarting or down, visitors now see a page that names your domain and explains what's happening, instead of a bare error.
One app can't slow down others. A single failing app no longer affects how quickly requests reach other sites.
bun.lock format (lockfile version 2) install correctly.New databases store their data on encrypted volumes, Git tokens are encrypted, deploy credentials stay out of your app, and our runtimes are patched against this week's Node.js and PHP advisories.
New databases are encrypted at rest. Databases created since October 18 store their data on encrypted volumes. Each volume has its own encryption key, and that key is itself encrypted and never stored in plain text. Existing databases keep their current storage.
Git tokens are encrypted. Access tokens for your connected Git providers are now stored encrypted.
Deploy credentials stay out of your app. The Git token and registry login used to build your app are no longer present in your app's environment at runtime.
Patched runtimes. Brimble's own services and the images we build your apps with were updated to Node.js 22.23.4 and PHP 8.2.35, covering the Node.js security release of October 21 and the PHP session upload advisories.
Updated certificate trust. Following the eMudhra compromise, our build image no longer trusts the emSign ECC Root CA - G3 and Comodo AAA Services root certificates. If a build downloads from a server whose certificate chains to one of these roots, that download will now fail.
Stop and start a database from its quick actions, see connection details instantly, and get databases that only report ready when they really are.
Stop and start. Databases now have Stop and Start in their quick actions. Starting a database that's been stopped for a long time works too: Brimble rebuilds what it needs and brings it back.
Connection details right away. The connect window shows your connection details as soon as it opens.
Ready means ready. A new database is only marked ready once it's actually healthy and accepting connections, not just once it's been scheduled.
More room for new databases. New databases can be placed on any server in their region, so creating one is less likely to fail in a busy region.
Database traffic isn't billed as bandwidth. Traffic to and from your databases no longer counts toward your bandwidth usage or overage.
Put a previous deployment back live without rebuilding. Brimble reruns its image with the environment variables it shipped with, and pauses automatic deploys until you're ready.
When a release goes wrong, you can now go straight back to a version that worked.
Roll back from deployment history. Open a project's deployment history, find the deployment you want, and choose Roll back to this. Brimble redeploys that deployment's image exactly as it was built, with the environment variables it ran with. There's no rebuild, so it's live in about the time it takes your app to start.
Your current variables are left alone. A rollback uses the variables pinned to the old deployment, but it doesn't change the variables in your project. Whatever is set there now applies to your next normal deploy.
Automatic deploys pause after a rollback. So a new push doesn't immediately undo the rollback, deploys on push to your production branch are paused. A banner in deployment history shows they're paused, with a Resume button. Deploying manually also resumes them.
The deployment just before the live one can always be rolled back. Beyond that, it depends on your plan:
Metrics, web analytics and logs now live together under one Observability tab, with a new route-by-route breakdown and total requests and egress for any time range.
One place to look. A project's metrics, web analytics and logs are now grouped under a single Observability tab, so you can move between them without hunting through the project menu.
Route activity. A new table shows the routes behind your traffic for the selected time range. For each method and path you get:
IDs in paths are grouped, so /users/123 and /users/456 show up together as /users/:id. You can search by method or path, and sort to find the slowest or noisiest routes.
Totals at a glance. The summary at the top now includes total requests and total data sent (egress) for the range you're looking at.
More time ranges. Last 30 minutes and Last 12 hours join the range picker. If a long range is slow to load, the page now tries shorter ranges automatically instead of failing.
Route activity is built from your project's request logs, so it covers traffic that reaches your app through Brimble.
Copy a single project, with its settings and variables, into staging or any other environment from the project menu.
Cloning a whole environment was already possible. Now you can copy just one project.
From the project menu. Open the project, choose More project actions → Duplicate project, and pick the environment it should go to. Brimble creates the copy there and starts its first deploy in the background, so you're not left waiting on the screen.
What comes across. The copy gets the same build and runtime settings, resources and environment variables as the original. Its Brimble domain gets the target environment's name added, so the two never clash.
Every build is checked against known critical vulnerabilities. If your app depends on an affected package, the deploy stops and tells you which version to upgrade to.
Brimble now checks your dependencies for critical security vulnerabilities as part of every build.
What's checked. The build scans your project's lockfiles and dependency files against a database of critical advisories that we refresh every day. It covers npm, PyPI, Go, Rust (crates.io), RubyGems, Composer (Packagist), Maven, NuGet, Hex, Pub, Swift, CRAN and Hackage packages.
What happens when something's found. The deploy stops before anything goes live, and the build log shows:
Upgrade the package, push again, and the deploy goes through.
dependencies block a deploy. Problems in packages pulled in by your dependencies are shown as a warning, and the deploy carries on. devDependencies are ignored.Turn on cross-environment access and services in every environment of your workspace can reach that service on its internal address, without making it public.
Private networking keeps environments apart by default: staging talks to staging, production to production. Sometimes you need an exception, such as a shared internal API or a single auth service that every environment uses.
Turn it on per service. In a service's Networking settings, switch on Cross-environment access. Services in every environment of your workspace can then reach it on its internal address. Nothing changes about its public access.
Turn it off any time. Switching it off goes back to the default, where only services in the same environment can reach it.
Get a short, private brimble.run link to any port in a running sandbox, so you can open the app inside it in a browser or share it with someone else.
Apps running inside a sandbox can now be opened from outside it.
Ask for a link to any port. Request a preview URL for a sandbox and a port, and you get back an address like https://<id>.brimble.run. Open it in a browser and you're talking to whatever is listening on that port inside the sandbox, whether that's a dev server, an API or a preview of a site an agent just built.
GET /v1/sandboxes/{id}/ports/{port}/preview-urlHard to guess. The address is an encrypted code for the sandbox and port, so it can't be worked out from the sandbox's ID.
Clear messages. If nothing is answering on that port yet, the page says so and asks you to start your app and refresh.
CockroachDB databases on Brimble now get automatic backups and restores, live Insights charts and a working data workbench.
CockroachDB now has the same day-to-day tooling as our other databases.
Backups and restores. CockroachDB databases are included in automatic backups, and you can restore them from backup history like any other database.
Insights. The Insights tab now shows CockroachDB metrics: query throughput, error rate, active and new connections, memory, disk usage, and disk reads and writes (IOPS).
Workbench. Turning on the data workbench now works for CockroachDB databases, with read access granted across your schemas.
Your cluster, your settings. New CockroachDB databases have diagnostics reporting turned off, and you can change cluster settings yourself.
Project issues warn when a database is smaller than its engine needs, when a service runs out of CPU, and when backups stop working. You also get an email when backups fail and when they recover.
Three new kinds of project issue catch problems before they turn into outages.
Databases below their recommended size. Each database engine has a recommended minimum amount of memory and CPU. If yours runs below it, an issue tells you exactly what it has and what's recommended, for example 1 GB of memory against 2 GB. Running undersized is a common cause of slow queries and out-of-memory restarts. The issue clears once you resize.
Services short on CPU. If a service averages more than its CPU allocation over 15 minutes, or sits above 90% of its CPU limit and is being slowed down to stay within it, an issue tells you how much it used. Give it more CPU, or look at what's using it. The issue clears on its own once usage drops.
Backups that keep failing. If a database's automatic backups have been failing for 24 hours, an issue opens and the database owner gets an email saying when the failures started. Our team is alerted as soon as failures begin. When backups succeed again, you get a second email letting you know a new restore point is available.
Billing, domains, environment variables, teams and databases: smaller fixes across the platform.
Click a line in your application logs to expand it in place and see the full message, its fields and where it came from, with one-click copy.
Application logs are easier to read and dig into.
Expand any line. Click a log line and its details open right below it, without leaving the list. Click it again to close it.
Each value has its own copy button, and Copy grabs the whole message.
Easier to scan. Log lines are separated by a light divider, so multi-line entries are easy to tell apart.
Open Cursor or Claude Code with Brimble already set up, straight from the dashboard or the website. Your API key is filled in for you.
Connecting a coding agent to Brimble no longer means finding an API key and editing config files.
From the dashboard. The Onboard your agent window now fills in your own API key. Copy the prompt or the setup for Claude Code, Cursor or Codex and it's ready to paste, with nothing to edit. Open in Cursor and Open in Claude Code go one step further and open the app with Brimble ready to add.
A key that's ready when you are. Every account now gets a default API key with sensible access to projects, environment variables and domains. You don't need to create one before connecting an agent, and it doesn't count toward your API key limit.
From the website. The Brimble homepage has a Connect your agent option. It opens Claude, Cursor or Claude Code with Brimble ready to add, and you sign in to Brimble when the agent asks.
Deploy, follow builds, stream logs, manage environment variables and brimble.toml, and connect your coding agents, all from your terminal.
Brimble now has an official command-line tool. Everything you'd normally click through in the dashboard, you can now do from your terminal or a CI job.
Install
brew install brimblehq/tap/brimbleOr with the install script on macOS and Linux:
curl -fsSL https://brimble-cli.t3.tigrisfiles.io/install.sh | shWindows builds are on the releases page. brimble upgrade updates the CLI in place, and it tells you when a new version is out, at most once a day.
Deploy and follow the build
brimble login
cd my-app
brimble deployIn a folder that isn't linked yet, brimble deploy offers to link an existing project or create a new one from GitHub, GitLab, Bitbucket, a Docker image, or a local folder uploaded as a static site. It then follows the build as it happens and exits with an error if the deployment fails, so it works as a CI step out of the box.
Everyday commands
brimble logs: stream live application logs.brimble env: list, set and remove environment variables.brimble status and brimble project stats: health, usage, and for databases, database metrics.brimble domain status: shows the DNS records to add and whether each one is set up.brimble team switch: change your default workspace.Run brimble link once in a project folder and every command there targets that project without arguments.
Config as code
brimble config pull writes brimble.toml from your project's current settings. brimble config validate checks it, and brimble config plan shows exactly what a change would do before you push. When a deploy is waiting for approval, brimble deploy shows the plan and lets you approve or reject it on the spot.
Coding agents
brimble mcp finds the coding agents on your machine and connects them to Brimble's MCP server in one step. It supports Claude Code, Cursor, VS Code (Copilot), Windsurf, Codex, Gemini CLI, opencode and Zed, with guided steps for Claude Desktop and Grok Build.
The full guide is at paper.brimble.io/cli/overview.
Builds reuse more work, apps start faster, and a set of edge cases that could fail a deploy or a redeploy are fixed.
Faster builds. Builds reuse your installed dependencies when they haven't changed, skip a duplicate image upload, and keep connections to the build servers open between steps.
Faster starts. New deployments get a guaranteed share of CPU while they boot, and apps that don't pin a Node.js version skip the version manager entirely.
Project issues now flag failing health checks, crashes and out-of-memory restarts in every app, and keep a history of resolved issues you can review or close yourself.
Project issues surface more of the problems that take an app down, and they now keep a record.
Failing health checks. If your app stops answering its health check, an issue tells you which path is failing and why, for example when nothing is accepting connections on your app's port. Brimble restarts the app while it fails, so this is usually the first sign something is wrong.
Crashes and memory limits in every app. Crash loops and out-of-memory restarts are now reported for every kind of deployment, not just some. When your app hits its memory limit, the issue says so, so you know to give it more memory or look at what's using it.
Resolved history. Issues that clear on their own aren't lost anymore. They move to a Resolved list, so you can see what happened and when. You can also resolve an issue yourself once you've dealt with it.
Redeploying a stopped project now tells you to start it first, instead of queueing a deploy that can't run.
Turn on preview collaboration and your team can leave comments directly on pull request previews, signed in automatically with no email codes.
Pull request previews now support preview collaboration, built with our partner Quality. Your team can comment directly on the page they're reviewing, instead of sending screenshots back and forth.
Turn it on per project. In your project's configuration, turn on Preview collaboration next to Preview deployments. Every new preview gets the commenting toolbar, with no changes to your code.
No extra sign-up. Team members are signed in to comments on shared previews automatically. Nobody has to wait for an email code before they can leave feedback.
Know what you're reviewing. Each comment is tied to the commit the preview was built from, so feedback lines up with the right version of your change.
External reviewers. Add people outside your team, like clients or designers, as external collaborators so they can comment too.
One project with preview collaboration is included. Each additional project is $6 per month.
See the preview collaboration guide in the docs at paper.brimble.io.
Turn previews on or off per project, see every live preview with its PR, commit and author, and read each preview's own logs and metrics.
Pull request previews got a full round of upgrades.
Turn previews on or off. Each project now has a Preview deployments toggle. When it's off, new pull requests don't build previews, and any existing preview URL stops serving. Flipping the toggle is saved instantly and doesn't trigger a redeploy of your production app.
See every live preview. The project overview lists active previews alongside your domains. Each one shows its branch, pull request number, latest commit, author and when it was last deployed, so you can jump straight to the preview you're reviewing. Only previews that are actually live and reachable are listed.
Logs and metrics per preview. The logs and metrics views have a preview selector. Pick a pull request and you see that preview's runtime logs, CPU and memory, not production's. Preview deployments in the deployment history carry a Preview · PR #n badge so they're easy to tell apart.
API keys now work on the Free plan, show your plan's daily request limit, count every request accurately, and come with a complete public API reference.
API keys on every plan. Free accounts can now create API keys. Creating a key used to fail on the Free plan.
Visible limits. The API keys page shows your plan's daily request limit, so you know how much headroom your scripts and agents have before they're throttled.
Predictable rate limiting. Requests are counted consistently, so you hit your limit when you expect to, not all at once.
Complete API reference. The public API documentation has been regenerated from the live API. It covers 14 areas: projects, environments, secrets, webhooks, Git providers, domains, databases, log drains, sandboxes, object storage, scaling and networking, teams and the catalog, with request and response shapes for every endpoint.
Validation errors from the API now use the same error format as every other error, so client code only has to handle one shape.
Turn whole categories of Brimble email on or off in settings, and unsubscribe from any email with a single click from your inbox.
Notification settings now group Brimble's emails into four categories, each with its own switch:
Every email we send is now tagged with its category, so your choices apply everywhere, including weekly usage reports, referral emails and email-forwarding notices that previously ignored them.
Every email now supports one-click unsubscribe. Use the unsubscribe link in the email, or the button your email app shows next to the sender, and that category is turned off immediately, with no login needed.
/settings/notifications in the dashboard.A month of hardening for managed databases: fewer unnecessary restarts, better Redis-family support, and more reliable recovery when something goes wrong.
We spent a lot of this cycle on the parts of managed databases you shouldn't have to think about.
Reliability
Engines
Analytics charts without gaps, static assets that load cross-origin, smoother environment switching, and a batch of fixes to deploys, teams and storage.
A roundup of fixes that shipped between mid-September and mid-October.
Analytics and observability
Deploys and projects
Dashboard
Builds now run in parallel across your projects, and a failed or outdated build can never take down the version that's already serving traffic.
Builds no longer queue behind each other one at a time. Your workspace now runs several builds at once, so a push to your API doesn't wait for your frontend to finish building. How many run at once depends on your plan: the Hacker, Developer and Team plans include 2 concurrent builds, and more can be added to your plan for $8 each. The Free plan still builds one at a time.
Alongside the extra speed, deploys are now much safer when several happen close together:
A guided setup connects your coding agent to Brimble over MCP, and agents can now start, stop and move projects and manage outbound IPs.
The dashboard has a new Onboard your agent flow that connects Claude Code, Cursor or Codex to Brimble through our MCP server. Pick your tool, copy the generated snippet, and your agent can deploy, read logs, manage variables, domains and databases, and debug failed builds for you, using the same permissions as your account.
The MCP server also gained new project tools:
Sign out of Brimble on every browser and device in one click, for when you've lost a laptop or used a shared computer.
Account settings now include Log out of all sessions. One click signs you out everywhere you're logged in to Brimble: other browsers, other computers, your phone and the current session too.
It takes effect immediately, and signed-out sessions can't be used again.
Runtime and request logs are now kept for exactly your plan's retention period: 7 days on Free, 30 on Hacker, and 90 on Developer and Team.
How long we keep your logs is now enforced consistently per account, based on your plan:
Runtime, build and request logs all follow the same rule, so you always know how far back you can look.
If you need logs for longer than your plan keeps them, set up a log drain to send them to your own storage or logging tool.
Domain renewals, auto-renew and transfers now work end to end with live pricing and correct expiry dates, plus quotes before you pay.
We rebuilt how domains bought through Brimble are renewed and transferred. Manual renewals and auto-renew use up-to-date pricing and keep your domain's expiry date and subscription in sync.
Transferring a domain into Brimble now works end to end. The dashboard shows a quote for renewing or transferring a domain before you pay, and domain search results show the renewal price next to the first-year price, so a cheap first year doesn't hide an expensive second one.
A new Issues menu shows what needs your attention on a project, like crash loops, repeated failed deploys, broken references or a database filling up.
Each project now has an Issues menu in the top bar, listing things that need your attention. Brimble watches your project in the background and opens an issue when it spots a problem, then closes it on its own once the problem is gone.
Issues are detected for:
Each issue shows when it was first and last seen, and how many times it has happened, so you can tell a one-off from an ongoing problem. Issues are informational. They never change or stop your project.
Point your domain at gateway.brimble.app and it keeps working even if one of our regions goes down. Root domains on Brimble DNS can now use CNAME too.
Custom domains now have a new address to point at: gateway.brimble.app. It fails over automatically between our regions, so if one region has a problem, traffic to your site moves to a healthy one without you changing anything.
The domain setup screen now shows exactly one recommended record per name. For subdomains like www, app and api, that's a CNAME to gateway.brimble.app. For root domains, use an ALIAS, ANAME or CNAME record if your DNS provider supports one on the root.
If your domain still uses our previous records, it keeps working and there's no downtime. To get the failover protection, update your records:
gateway.brimble.app.gateway.brimble.app, or move your nameservers to Brimble if your provider only allows A records on the root.Domains already on Brimble DNS were updated automatically. Owners of domains that need a manual change are being notified by email.
Spin up staging from production, or production from staging, by cloning an environment's projects, variables, sandboxes and buckets in one go.
You can now create a new environment by cloning an existing one. Pick what to bring across, and Brimble rebuilds it in the new environment: your projects with their settings and per-project variables, the environment's shared variables, sandboxes, and storage bucket configuration.
Cloned projects keep their original names. Project names are now unique per environment rather than per workspace, so api in Production and api in Staging can live side by side. References between projects, like {{@api.DATABASE_URL}}, keep working in the new environment without any edits, because they resolve to the cloned api there.
myapp.brimble.app becomes myapp-staging.brimble.app. Your custom domains are never copied or moved. They stay attached to the original environment, and the clone summary lists them so you can decide what to attach.Use New environment → Clone from in the environment switcher, choose a source environment, and tick what to include. Projects, variables, sandboxes and buckets are opt-in individually. Bucket cloning copies configuration only, not the objects inside.
Brimble now warns you in the dashboard when build minutes run low and emails you the moment they run out, so a stalled deploy never comes as a surprise.
Running out of build minutes used to show up as a deploy that wouldn't start. Now you hear about it first. When your included build minutes are running low, a notice appears in the dashboard showing how much you have left. When they're used up, you get an email explaining what happened and how to keep deploying.
Both the notice and the email link straight to billing, where you can buy more minutes or change your plan. Teams get the same alerts, sent to the people who manage billing.
A Team plan seat now covers the owner plus two teammates, so small teams pay for one seat, and the billing page shows exactly what each line costs.
Team pricing is simpler and cheaper for small teams. A Team plan seat now covers the owner and two more people, so a team of one, two or three pays for a single seat. Each additional person adds one seat at the normal price. Seats are counted from accepted members only, so pending invites don't cost anything.
Existing teams have been moved to the new seat rule automatically.
Describe your services, databases, buckets and environments in a brimble.toml file in your repo. Brimble applies safe changes on push and asks before risky ones.
You can now manage your Brimble setup from a brimble.toml file committed alongside your code. On every push, Brimble reads the file, works out what's different from your current setup, and applies it as part of the deploy.
A single file can describe:
{{@db.PRIVATE_CONNECTION_STRING}}.Not every change should happen silently. Changes that cost money or are hard to undo, such as creating a new resource, attaching a domain, changing region, growing storage or switching on TLS or pooling, pause the deploy with an Awaiting approval status. You review the plan in the dashboard and approve or reject it. Changes that can't be applied at all fail the deploy with a clear reason instead of half-applying.
Any paid plan can now deploy to any available region, with each region's price shown upfront, plus lower minimum sizes for small services.
Regions are no longer locked to particular plans. Any paid plan can deploy web services and databases to any enabled region that has capacity. Instead of an upgrade wall, each region carries a pricing factor that reflects what it costs us to run there. The region picker and the cost estimate show the real price before you deploy.
The same regional rates apply consistently across compute, persistent volumes and object storage, so the number in the estimate matches the number on your invoice.
Top up a credit wallet and pay for subscriptions, domains and add-ons from it, including with local currency, mobile money, bank transfer or crypto.
Personal accounts and teams now have a credit wallet. Add credit once and Brimble uses it to pay for things automatically: subscriptions and renewals, plan and seat changes, domains, build minutes and add-ons. Every top-up and payment is listed in a ledger with a running balance and a downloadable receipt.
You can fund the wallet two ways:
Store files in S3-compatible buckets in our new Lagos region, close to African users, and link any bucket to your projects without copying keys around.
Object storage now has a Lagos region. Buckets there are fully S3-compatible, so the AWS CLI, the AWS SDKs and any S3 client work out of the box, including large multipart uploads. If your users are in West Africa, storing files in Lagos keeps uploads and downloads fast.
You can also now link a bucket to your projects. Choose a bucket and the projects that should use it (in the same environment), and Brimble writes the standard variables onto each project: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION, AWS_ENDPOINT_URL and AWS_S3_BUCKET. They're stored as references to the bucket, not copied secrets, so there's nothing to paste and nothing to keep in sync by hand.
objects.brimble.io.Build your own team roles from a list of individual permissions, and limit members to the environments they actually work in.
Team access control has been rebuilt. Alongside the built-in roles, team creators can now define custom roles, picking exactly which actions a role allows: deploying, editing variables, managing domains, running terminal commands, reading logs, managing storage and more. If none of the built-in roles fits someone's job, make one that does.
Roles can also be scoped to environments. A contractor can be a Member of Staging only. A support engineer can be a Viewer of Production only. Anyone with an environment-scoped role simply doesn't see, or can't act on, resources outside the environments they've been assigned.
Set your own backup retention, send database backups to a Brimble bucket or any S3-compatible storage, and schedule them in your own timezone.
Database backups are now much more configurable. Under Backups → Settings you can decide how long backups are kept and where they're stored, instead of living with one fixed policy.
There are three destinations:
Custom retention and custom destinations are available on the Developer and Team plans. Other paid plans keep their plan's default retention on Brimble storage.
Every service now gets an internal address on Brimble's private network, so your apps and databases can talk to each other without going over the internet.
Your services now each have an internal address, shown in the project's Private networking section. It looks like api.virtual.brimble.internal:8000 and only resolves from inside your workspace. Calls between your own services, such as a frontend talking to its API or a worker talking to a queue, can use it instead of the public domain.
Traffic over the private network never leaves Brimble, so it's faster, it isn't counted as public bandwidth, and it isn't exposed to the internet. A service can also be made private-only: turn off public access and it's reachable solely through its internal address, which is ideal for internal APIs and background services.
Run commands inside your web service or worker straight from the dashboard, with a full interactive shell or one-off commands from the API and MCP.
Web services and workers now have a Console tab with a real terminal attached to your running app. Use it to run a database migration, inspect a file, check an environment variable, open a REPL or debug a misbehaving process, without setting up SSH or redeploying with extra logging.
The terminal is fully interactive, so tools like top, vim and language REPLs work as you'd expect, and it resizes with your window. Each terminal tab is its own session that remembers your working directory, so cd sticks between commands.
Not everything needs an open shell. You can also run a single command and get back its output and exit code, from the API or from your AI agent through the Brimble MCP server. That's handy for scripted maintenance like "run the migration, then report the result".
Give a project stable outbound IP addresses you can allowlist with banks, payment providers, databases and partner APIs that only accept known IPs.
Some services only accept traffic from IP addresses you've registered with them: payment processors, banking APIs, managed databases behind a firewall, enterprise partners. Until now, outbound traffic from your app didn't come from a fixed address, which made that impossible.
You can now turn on Dedicated outbound IPs for a project. Once it's on, every outbound connection your app makes leaves through a fixed set of IP addresses for your project's region. The dashboard lists those addresses so you can paste them straight into your provider's allowlist. Changes take effect within seconds, without a redeploy.
Receive mail at addresses like [email protected] and forward it to any inbox you already use, with the DNS records set up for you.
Domains managed on Brimble DNS can now forward email. Create an alias such as hello@, support@ or billing@ on your domain, choose the inbox it should go to, and incoming mail is delivered there. No separate email provider and no records to copy by hand.
When you create your first alias, Brimble adds the MX, SPF and DKIM records your domain needs and marks them as managed, so they won't be broken by accident when you edit other DNS records. If your domain already has an SPF record, the forwarding sender is merged into it rather than replacing it.
Database Insights now turns your live metrics into a ranked list of concrete fixes, from missing indexes to connection pressure, tailored to your engine.
Database Insights already charted load, connections, slow operations and disk usage. It now also tells you what to do about them. Brimble reads your database's recent metrics and query statistics and produces a ranked list of recommendations written for your specific engine, whether that's Postgres, MySQL, MongoDB, ClickHouse, Redis or another supported database.
Each recommendation comes with a severity (Critical, Attention or Suggestion), an impact score so you know what to tackle first, and a category: indexing, query optimisation, schema design and integrity, storage, connections, memory, replication, configuration or throughput. Instead of a generic tip, you get something like "this query scans the whole table on every call; an index on these columns would remove it."
pg_stat_statements enabled, which gives the recommendations real per-query data to work from.Run MongoDB or Postgres as a three-node cluster spread across regions, with automatic failover so a lost node no longer means a lost database.
Managed MongoDB and Postgres can now run as a high-availability cluster. Instead of a single database container, Brimble provisions three members: a primary in the region you pick and two replicas in two secondary regions of your choice. If the primary goes down, a replica is promoted and your application keeps writing without you touching anything.
MongoDB runs as a native replica set. Postgres runs as a managed cluster with automatic leader election, and connection strings carry target_session_attrs=read-write, so standard drivers always find the current writer. Connection pooling with PgBouncer is available on Postgres HA clusters and always routes to the live primary.
New databases now report each provisioning step live in the dashboard, so you can see exactly what's happening instead of watching a spinner.
Creating a database used to show a single "in progress" state until it was suddenly ready, or suddenly failed. Provisioning now streams its progress to the dashboard as it happens: preparing storage, starting the database, setting up users and networking, and finally marking it ready.
This matters most for larger setups. A three-node high-availability cluster has many more steps than a single container, and each member reports in as it joins. If something goes wrong, the step that failed is the one you see, which makes the error far easier to act on or to share with support.
Successful referrals earn domain purchase credits and invoice discounts — Developer trials do not count as conversions.
When someone you refer converts, you can earn a domain purchase credit and an invoice discount up to the reward cap. Domain checkout can apply those credits so the reward shows up where it matters.
Trialing Developer subscriptions are excluded from conversion, which keeps rewards tied to real paid outcomes rather than short trials.
Rotating a managed database password emails the account owner so unexpected changes are hard to miss.
When a managed database password is changed, the account owner gets an email confirmation with a link back to the database project.
If you did not make the change, the message makes that obvious — a simple security signal for a credential that otherwise only lives in a password manager.
Point a single `*` DNS record at your project and cover every nested subdomain without adding each hostname by hand.
You can now enable wildcard custom domains on eligible plans. Once DNS is set up, nested subdomains like api.example.com and staging.example.com resolve to the same project without creating a separate domain mapping for each one.
Setup walks you through the * record and the challenge CNAME needed for TLS, so certificates can be issued for matching subdomains as traffic arrives. Useful when you ship previews, tenant apps, or environments under one apex.
Expose HTTP-protocol managed databases on public `*.db.brimble.app` hostnames from the project UI.
HTTP-capable database engines can be provisioned with public domain routing, including region-aware *.db.brimble.app hostnames. The dashboard shows database-specific domain copy and connection details so you know exactly what to paste into your client.
That makes engines which speak HTTP first-class for apps that expect a URL endpoint rather than a classic host/port DSN.
Create additional database users with readonly or readwrite access so teammates and services do not share the primary password.
Supported managed databases now let you create extra users scoped to one or more logical databases. Pick readonly or readwrite access depending on whether someone needs to query or write.
Passwords are shown only when you create or rotate a user, then you store them where your team keeps secrets. That makes it safer to give CI, analytics tools, or collaborators their own credentials instead of reusing the owner login.
Dockerfile builds now receive project env files so build-time config (rewrites, public keys, feature flags) resolves correctly.
Docker image builds copy project environment into the build context instead of stripping those files away. Frameworks that evaluate config at build time — Next.js rewrites and public env are the usual suspects — finally see the same values you set in the dashboard.
If a previous Docker deploy built with missing env and weird runtime behavior, redeploy after this fix.
Deploy region pickers warn when a region is tight on capacity, and builds fail clearly instead of hanging when a region is full.
Deploy flows check regional capacity and surface warnings in tooltips before you commit to a full region. You can still redeploy onto busy nodes when that is the right call, but you are not guessing in the dark.
If a region is exhausted, the build fails with a clear capacity error instead of sitting in a queue that never progresses — so you can pick another region and move on.
Custom domains on multi-part TLDs like `.co.uk` now detect the real apex instead of treating the wrong label as the root.
DNS and domain validation now use proper public-suffix apex detection for multi-part TLDs. Domains such as example.co.uk are handled as apex vs subdomain correctly.
That fixes broken DNS guidance and mapping for ccTLDs and other compound suffixes where a naive "last two labels" rule gets the apex wrong.
Closing a pull request now cancels any active preview builds for that PR instead of letting them finish for nothing.
When a pull request is closed, Brimble cancels active preview builds tied to that PR. Merged or abandoned branches no longer keep runners busy building something nobody will open.
That frees build capacity for the PRs that are still open and stops surprise minutes on closed work.
Provision LibSQL as a managed database on Brimble — with workbench access and connection options that fit how your app talks to it.
LibSQL joins the managed database lineup. Spin one up from the project UI, get connection details immediately, and open the workbench to explore data without leaving the dashboard.
Where the engine supports it, you can use HTTP-friendly public connection URLs alongside native protocol connections — so serverless and edge-style apps have a path that matches how they connect today.
Verify GitHub, GitLab, Bitbucket, and Origin connections before a deploy, and keep builds moving when some runners are down.
Git provider connections can be health-checked so expired installs, revoked access, or broken webhooks surface before you hit Deploy. Fix the connection first; do not discover it mid-build.
Build scheduling is also more resilient when some runners are unavailable — work redistributes instead of stalling the whole queue behind a dead node.
Forecasted bills no longer mix in unpaid invoices or invent phantom bandwidth overages around cycle resets.
Bill forecasts exclude unpaid invoices and no longer show incorrect bandwidth overages when a billing cycle resets. What you see as "projected" is closer to what you will actually owe.
High-availability standby capacity is not charged as an extra instance, and payment-failed cancels are classified separately from cancels you requested — so billing history reads correctly when something goes wrong.
Connect Cursor Origin repositories and deploy from Origin pushes the same way you do with GitHub or GitLab.
Cursor Origin is now an installable git provider. Connect it with OAuth, receive webhooks, and ship from Origin pushes alongside the providers you already use.
Push events map into builds like every other git integration, so teams living in Origin do not need a second remote just to deploy on Brimble.
Monthly spending limits can either notify you or pause compute and block new deploys when you hit the cap.
Spending limits now support two actions: notify, or pause. Notify keeps you informed without interrupting work. Pause disables new deploys and sandboxes and stops running compute once the limit is exceeded.
Raise the limit or switch back to notify to resume. That gives budget-conscious teams a hard stop without deleting projects.
Star the projects and storage buckets you reach for most so they stay easy to find.
Projects and storage buckets can be starred from the dashboard. Mark the ones you live in every day and leave the rest of the list for when you need them.
Starred items stay marked across sessions, which is a small quality-of-life win when an account has grown past a handful of resources.
Corrected marketplace pricing for `.ai` and related TLDs so quotes match what you are charged.
Domain marketplace quotes for .ai and related TLDs now use corrected pricing. Purchase flows no longer show an amount that disagrees with checkout.
If you compared quotes recently and something looked off on those TLDs, refresh the search — the numbers should line up.
When a repo has more than one Dockerfile, choose which one Brimble should build on create and redeploy.
Framework detection now finds Dockerfiles in the project root and flags when more than one exists. Create and redeploy flows let you pick the Dockerfile that matches the service you are shipping.
Monorepos and dual-target apps (API vs worker, prod vs debug) no longer depend on an implicit default that builds the wrong file.
Platform hostnames keep stable certificates across edge restarts, while your custom domains continue on-demand TLS as usual.
Platform hostnames on *.brimble.io / *.brimble.app stay on their dedicated certificates so an edge restart no longer requests the wrong certificate for those hosts. Mapped custom domains keep using on-demand TLS the way they always have.
Related edge fixes restore correct upstream Host headers and keep rate limiting effective when a cache sits in front of your project — so routing and protection behave after restarts the same as before.
Pay for domain purchases and LLM token top-ups with crypto checkout — no card required for those flows.
Domain purchases and LLM token wallet top-ups can be paid through crypto checkout links. Complete payment in the wallet flow you already use, and Brimble credits the purchase when the payment succeeds.
If card payments are awkward for your team or region, those two high-frequency flows now have another path.
Publish a static site by uploading files or a zip — no git repository required, ideal for handoffs and one-off landings.
Static sites can go live through a file or zip upload flow. Drop in a built site, confirm, and publish without connecting GitHub, GitLab, or another provider first.
Uploads are size-checked and staged before publish, which is ideal for marketing sites, design handoffs, or one-off landings where a full git workflow is more ceremony than you need.
Plan changes keep active personal trials intact when a downgrade is scheduled, and outstanding invoices are handled more accurately.
Scheduling a plan downgrade no longer quietly eats an active personal trial. You keep the trial window you already started while the future plan change stays on the calendar.
Upgrade and downgrade handling also accounts for outstanding invoices more carefully, so billing state after a plan change matches what you expect on the next invoice.
Schedule commands on workers and web services, inspect run history, and force a run when you need it now.
Workers and web services can run scheduled commands with expression validation and timezone helpers. Define the job once and let Brimble fire it on schedule.
Run history shows what executed and when, and a manual force-run is there for the moments you need to reprocess a batch or verify a fix without waiting for the next tick.
Start or stop non-database services from the dashboard without deleting the project.
Web and similar services can be started or stopped from the dashboard while keeping the project, env, and domains intact. Pause something for the weekend or after a demo without tearing it down.
Status waits for allocations to settle so what you see in the UI matches what is actually running before you walk away.
Create scoped Brimble API keys from account settings and complete MCP OAuth connect without dropping your dashboard session.
Account settings let you create Brimble API keys with permission groups and expiry. Give each integration only the scopes it needs instead of a full-privilege token.
An MCP OAuth connect flow authenticates tools with those scopes while keeping your dashboard session during the handoff — so connecting an AI client does not feel like logging out of Brimble.
Set automatic backup schedules for managed databases, then download or restore from the Backups & Restore page.
You can configure recurring backup schedules for managed databases and manage history from Backups & Restore — including download and restore when you need to recover.
Schedules stay reconciled after you change them, and support has expanded across more engines (including Redis, LibSQL, and ClickHouse). Less manual snapshotting, more confidence that yesterday's data is still there.
Manage project Files in the dashboard and mount them into running services at the paths you choose.
Projects gain a Files tab for configuration that deploys with your service. Mark files public or secret and mount them at the paths your app expects — without stuffing everything into env vars or rebuilding from git for every config tweak.
Useful for nginx snippets, Firebase/service-account JSON, feature flags files, and other config that belongs on disk next to the process.
Explore detailed usage insights, export a PDF cost report, and get a weekly cost analysis email between invoices.
Usage insights break down compute and related spend so you can see where money is going before the monthly invoice arrives. Export a PDF when you need something shareable for finance or a customer conversation.
A weekly cost analysis email keeps the signal coming even when nobody opens the billing page — useful for catching a runaway service early.
Turn on PgBouncer pooling for Postgres-compatible managed databases and connect through a pooled endpoint.
Postgres-family managed databases can run with PgBouncer so short-lived app connections share a smaller pool of real database connections. You can tune pool settings from the dashboard instead of managing a sidecar yourself.
Connection details include helpers for the pooled URI, which is especially useful for serverless and high-churn apps that open many connections per deploy.
Pin Node and other supported runtime versions on web-service builds so deploys use the toolchain you expect.
Projects can select supported runtime versions from configuration. Builds and starts use that pinned toolchain instead of whatever default the platform happened to pick.
When an app needs a specific language major — for native modules, framework requirements, or parity with local — set it once and keep deploys consistent.
See query load, top operations, connections, and resource trends for managed databases in one Insights view.
Managed databases ship with an Insights view that charts load, connections, disk usage, and the operations that dominate traffic. When something feels slow, you can spot hot queries and connection spikes without wiring up a separate observability stack first.
Metrics come from engines that expose them — including MySQL performance schema and ClickHouse where available — so what you see matches what the database is actually doing.
Enable TLS on supported managed databases and download the certificate material you need from connection details.
Supported managed databases can enable TLS so public connection strings use encrypted transport end to end. Turn it on from the database settings when your image supports it.
Certificate material is available from connection details once TLS is enabled, so clients and ORMs that require a CA or verify-full mode have what they need without opening a support ticket.
Apply coupons at domain checkout — including coupons assigned to a specific person by email.
Domain checkout supports purchase coupons. Eligible codes reduce the quote you see before you pay, so promotions and partner deals show up in the flow instead of needing a manual invoice adjustment.
Coupons can also be assigned to a specific user by email. When one is created for you, you get a notification — useful for win-backs, credits, and one-off goodwill without handing out a global code.
Forward project logs to HTTPS or S3 destinations, with automatic disable when a drain keeps failing.
You can attach log drains to a project and stream application logs to HTTPS endpoints or S3 from settings and the project logs page. Keep your existing log stack; Brimble just ships the lines there.
If a destination starts failing, owners are notified and broken drains can be auto-disabled so retries do not pile up silently. Fix the destination, re-enable, and shipping resumes.
Zero-downtime cutover waits until the new allocation is healthy before traffic switches over.
Zero-downtime deploys use stricter health gates. Traffic does not move to a new allocation that is still failing checks, which cuts down on the brief outages that looked like "it deployed but the site flickered."
Grace for slow-booting apps was lengthened, and mesh networking for temporary containers during deploy was hardened — so apps that take a moment to warm up get a fair chance before cutover.
Sign-in and signup are more reliable across email, social login, refresh sessions, and magic-link codes.
Authentication flows for email and social login were rebuilt for consistency. Social signup stays in sync with your Brimble account, refresh sessions rotate server-side, and magic-link OTP codes keep leading zeros intact.
Duplicate accounts from email casing differences are also prevented — so [email protected] and [email protected] no longer become two people.
Define metric-based alert rules on a project and review when they fire — before customers notice the spike.
Projects can define alert rules on metrics and track when those alerts fire. Set thresholds that match how your service behaves, then get notified when reality diverges.
Alongside alerts, DNS change history is easier to audit from the dashboard sidesheet — so networking and reliability investigations stay in one place.
Run queries and browse schemas for managed databases without leaving the Brimble dashboard.
Managed databases now include a built-in workbench. Open it from the project, run SQL (or the engine's query language), and inspect tables and schemas in place.
Relational engines can also show an ERD-style schema view when available — handy when you are debugging a migration, checking indexes, or onboarding someone who has never seen the data model.
Reach managed databases over the private service mesh with internal hostnames — no public exposure required.
Managed databases can join the private Connect mesh. Apps in the same mesh get private connection strings and internal hostnames, so database traffic stays off the public internet.
This is the path you want when services and databases live together on Brimble and you would rather not open a public port just for app-to-database traffic.
Start a Developer plan trial from the static-site deploy confirmation — unlock domains and analytics before you go live.
When you finish configuring a static site deploy, you can start a Developer plan trial right in the confirmation step. There is no detour through billing settings just to unlock the plan for that first ship.
That keeps the moment of publish aligned with the features you actually need — custom domains, analytics, and the rest of Developer — so trial signup feels like part of deploy, not a separate chore.
Configure rate limits and edge caching rules per project to protect your services and improve performance for repeat visitors.
You can now set rate limiting rules on any deployed project. Define thresholds per route or across the entire project, and requests that exceed them are rejected at the edge before they reach your application. Rules sync automatically to Cloudflare's global network, so enforcement happens close to the user with no added latency.
Edge caching is also now configurable per project. Static assets and eligible responses are served from Cloudflare's edge, reducing origin load and improving response times for returning visitors. Both features are managed from the project networking settings in the dashboard.
Rate limiting is available on paid plans.
Submit and track support requests directly from the Brimble dashboard without switching to email or an external tool.
A new support ticket flow is available directly inside the dashboard. Describe your issue, submit it, and it's routed to the team — no need to open a separate email thread or navigate to an external support portal.
This keeps your context intact. You're already looking at the project, the deployment, or the error when you need help — now you can ask for it right there.
Move an existing storage bucket from one provider to another without re-uploading your files.
You can now migrate a storage bucket between backing providers — for example, moving from Cloudflare R2 to Tigris or vice versa — directly from the dashboard. The migration transfers your objects, folder structure, and bucket configuration to the new provider without requiring you to re-upload anything manually.
This is useful if your usage patterns change and a different provider offers better performance or pricing characteristics for your workload. The migration runs in the background; your bucket remains accessible during the process, and the URL endpoint stays the same once the switch completes.
Create S3-compatible storage buckets directly from the dashboard — with CORS, lifecycle rules, access controls, and your choice of storage provider.
Brimble now offers managed object storage as a first-class project type. Create a storage bucket from the dashboard, upload files, and access them over an S3-compatible API — the same interface your tools and SDKs already speak.
What ships with launch:
Object storage is useful for user uploads, static assets, backups, dataset hosting, and anything else that doesn't belong in a database. Buckets are billed on storage consumed, with no egress fees on R2-backed buckets.
Dashboard search keeps up as you type, and deployment logs are full-text searchable so you can jump straight to the line that matters.
Search across the dashboard is faster and more responsive, with results updating as you type. The deployment log viewer now supports full-text search, so you can jump directly to the line you are looking for instead of scrolling through pages of output.
The deployment history page also no longer gets stuck in a loading state when navigating between projects — a quiet reliability fix that shows up every time you hop between apps.
The build engine now auto-detects Bun alongside npm, yarn, and pnpm — no manual configuration required.
Brimble's build engine now recognizes Bun as a package manager. If your project uses a bun.lockb lockfile, builds will automatically use Bun for dependency installation and script execution — no need to override the install or build commands manually.
This brings Bun to parity with npm, yarn, and pnpm as a first-class package manager in the deployment pipeline. Projects that were previously working around Bun detection with custom build commands can now remove those overrides.
Managed object storage with full S3 compatibility, folder management, and configurable access policies.
Brimble now includes managed object storage with full S3 compatibility. You can create buckets, upload files and organize them into folders, and configure CORS rules, lifecycle policies, and access controls directly from the dashboard.
Storage is provisioned instantly and backed by globally distributed infrastructure. Each plan tier includes a bucket allowance, so storage scales with your subscription. Whether you need to serve user-uploaded assets, store build artifacts, or manage static files alongside your deployments, object storage is now a first-class part of the platform.
Automated email reminders before your Brimble-purchased domains expire, so you never lose a domain by accident.
If you purchased a domain through Brimble, you will now receive email reminders as the expiry date approaches. The reminders give you enough lead time to renew or let the domain go intentionally — no more discovering an expired domain after your site goes down.
Reminders are sent automatically for all domains purchased through the Brimble marketplace. No configuration needed.
Product updates and announcements now surface directly inside the dashboard, so you see what's new without leaving your workflow.
A new announcement component appears in the dashboard when there's something worth knowing — a new feature launch, a platform update, or a relevant notice. Announcements are dismissible and non-intrusive; they won't block your workflow or stack up.
This replaces the pattern of relying solely on email or the changelog page to communicate updates. If you're already in the dashboard, you'll see the news where you're already working.
Inject environment variables into sandbox runtimes for API keys, config, and secrets.
Sandboxes now accept environment variables that are injected into the runtime before your code executes. Set API keys, database URLs, feature flags, or any configuration your code needs — they're available automatically whether you're running Python, Node.js, or another supported language.
This makes it practical to use sandboxes for integration testing and prototyping against real services, without hardcoding credentials into your scripts.
Spin up an isolated, ephemeral sandbox to run code, test a build, or evaluate a snippet — with auto-destroy timers, one-shot mode, and outbound network controls.
Sandboxes are a new project type on Brimble: lightweight, isolated environments you can spin up to run code, test a deployment, or evaluate something you're not ready to commit to a long-lived project. Each sandbox has its own runtime, its own filesystem, and its own boundary — and disappears cleanly when you're done.
What you get out of the box:
Sandboxes are useful for anything you'd otherwise spin up a one-off container or VM for — quick experiments, untrusted code evaluation, scheduled tasks, ephemeral build environments. They're billed per second of actual runtime, so a thirty-second job costs about what you'd expect.
Spin up a sandbox from a template instead of starting from scratch — public templates cover common stacks, with previews and ready-to-use images.
A public template gallery is now available for sandboxes. Pick a template — covering common runtimes, frameworks, and tool stacks — and the sandbox provisions with the right image, dependencies, and starting files already in place.
Each template includes a preview image so you can see what you're getting before you launch, and templates can be filtered by category. Going from idea to running sandbox is now a single click for the common cases.
Drop a folder of files into a sandbox in one go, and sandboxes now provision noticeably faster — especially for templates with pre-warmed images.
A pair of sandbox usability wins:
Notification overflow fixes, project page scaling, domain transfer UI refinements, and a more readable AI debug experience.
A round of interface refinements across the dashboard. Notification panels now handle longer messages without clipping or overflow. Project pages scale more gracefully across different screen sizes. The domain transfer flow received layout adjustments for clarity.
AI-assisted debug responses are now trimmed to a readable length, so build failure explanations stay focused instead of running long.
Open a terminal into any sandbox from the dashboard — sessions persist across page reloads, with cwd and history streamed back so you don't lose context.
Every sandbox now has an interactive terminal you can open directly from the dashboard. A few details that make it actually usable:
cd around, the terminal UI shows your resolved current directory in real time, so you always know exactly where you are.Sandboxes can now keep state across restarts — pause and resume to save compute, and snapshot a running sandbox to clone it or roll back later.
Sandboxes are now stateful when you want them to be. The new capabilities:
Fire-and-forget ephemeral sandboxes still work exactly as they did last week — persistence is opt-in.
Put any deployment behind a password — perfect for staging environments, internal tools, and pre-launch previews you want to share without making them public.
You can now put any deployment behind a password directly from the project settings. Visitors hit a clean prompt for the shared password before the site loads — no Brimble account required, no third-party SSO setup.
A few uses worth highlighting:
Password protection applies across every URL on the deployment, including pull request previews. Rotate or remove the password at any time from project settings; changes take effect on the next request.
Set the CPU and memory your app should run with using sliders in the deploy form — available for both Git-based and Docker deployments.
The deploy form now exposes CPU and memory sliders, so you can size your application's runtime resources without leaving the new-project flow. Available for both Git-based deployments and Docker deployments.
A few details:
Useful for apps that are heavier than the default (image processing, ML inference, larger Node servers) and for apps that are lighter than the default where you want to save on compute.
Move a domain from your personal account to a team, or between teams, without buying it again or breaking DNS records — confirmed with step-up 2FA for safety.
You can now transfer a domain from one workspace to another directly from the domain settings page. Move a personal domain into your team's workspace, hand a domain off to a different team, or consolidate domains under one account — without losing DNS records, registrar history, or active project attachments.
Because domain transfers are high-impact, the action is gated behind a step-up 2FA prompt. We'll ask for a fresh code at the moment of transfer even if you're already signed in, so a forgotten session can't accidentally move a domain to the wrong workspace.
DNS records and certificate provisioning carry over automatically. If the domain was pointing at a project in the source workspace, you'll see a clear prompt to either keep that attachment or re-attach it to a project in the new workspace.
Team admins can require every workspace member to enable 2FA — with a non-dismissible setup prompt for members who haven't enrolled yet.
Workspace admins can now require all team members to have two-factor authentication enabled. Flip the switch in workspace security settings and:
When combined with step-up 2FA for destructive actions (shipped last week), it gives teams a clear story to tell their security reviewers.
You can now remove your last card on file — with a clear warning about what happens next — instead of being locked into keeping a card you no longer use.
Until now, you couldn't remove your last payment method while a paid plan was active. We've changed that: you can now remove your last card, with a clear warning explaining what'll happen at the next renewal (downgrade to free, or cancellation, depending on your plan).
We also added an inline 'add card' action directly from the purchase modal, so adding a new card mid-flow doesn't require leaving the screen you're on.
Sensitive actions like deleting a project, removing a teammate, or rotating an API key now prompt for 2FA verification at the moment of action, even if you're already signed in.
Brimble now does step-up authentication for actions with real consequences. When you go to delete a project, remove a team member, transfer ownership, rotate an API key, or any other destructive action, you'll be asked for a fresh 2FA code at the moment of action — even if you signed in hours ago.
This closes the window where a stolen session could be used to do real damage, and it gives you a confirmation moment before anything irreversible happens. The extra step is only triggered for destructive actions; everyday usage is unaffected.
If you have 2FA enabled, this is automatic. If you haven't enabled 2FA yet, sensitive actions still work — but they're a good reason to turn it on.
Cards that require 3D Secure now work end to end — add-card and checkout flows handle the bank challenge inline and confirm the payment automatically once you authenticate.
Brimble's card payment flows now fully support 3D Secure (3DS) authentication. When your bank requires the extra challenge — common for European cards, Indian cards, and any card flagged for review — you'll see the bank's authentication prompt inline and your payment completes automatically once you approve.
This applies across:
If your bank requires SCA for every transaction, this means Brimble now works for you the same way it does for everyone else. No more cards being declined because the challenge couldn't complete.
When you cancel a subscription or disable a project, we now ask why — your answer goes straight to the product team and helps us prioritise what to fix.
We added a short reason capture on subscription cancellations and project disable flows. Pick from a list of common reasons (price, missing feature, switched providers, project ended, etc.) or write a free-form response.
We read every one of these. They drive what we prioritise next, and recurring themes shape the roadmap. If you've ever wondered whether feedback at cancellation actually matters — at Brimble, it does.
The DNS layer for Brimble-purchased domains now runs on CoreDNS with multi-region failover — name resolution stays fast and available even if a single region has issues.
We moved the DNS resolution layer for Brimble-purchased domains onto a CoreDNS-based stack with multi-region failover built in. If one of our DNS regions has a network blip or upstream issue, queries automatically route through a healthy region without missing a beat.
What it means in practice:
Quiet under the hood, but it's the kind of change you only notice when something doesn't go wrong.
Dashboard navigation is noticeably snappier, page-load skeletons match the actual layout, and dropdowns are now fully keyboard-accessible.
A round of dashboard polish focused on perceived speed and accessibility:
Spin up a managed database on the free plan and get 15 days to evaluate it — full feature parity, real-time provisioning, with caps tuned for evaluation.
Managed databases now have a free 15-day trial on the free plan. Provision a Postgres, MySQL, MongoDB, or Redis database from the dashboard without a credit card, and you get the full feature set for 15 days — the only differences from a paid database are sensible evaluation caps on size and connections.
A few things that come with it:
requested to provisioned — no polling, no manual refresh.A new edge load balancer in the Asia region brings traffic for Asian users to a nearby POP instead of crossing oceans, cutting round-trip latency for projects with audiences in Asia-Pacific.
We expanded Brimble's global routing footprint with a new edge load balancer in the Asia region. Requests from users in Singapore, Tokyo, Mumbai, Jakarta, and the rest of Asia-Pacific now terminate at the new Asia POP instead of being routed to a balancer in another continent.
The practical impact:
Combined with our European load balancer in Frankfurt, your projects now have proper coverage across Europe and Asia by default.
AI debug suggestions can now produce significantly longer, more detailed responses for complex failures — full code blocks and multi-step fixes fit cleanly without truncation.
The response budget for AI debug suggestions has been raised, so the assistant can return fuller fixes for complex failures. Multi-file changes, full code blocks, and step-by-step explanations now fit within a single suggestion instead of getting cut off mid-thought.
For common failures, the experience is unchanged. For the gnarly ones, you'll get a noticeably more useful first response.
Build logs now show a phase rail, follow new output as it streams, and let you copy a selection or the entire log with one action.
The build log viewer in the dashboard got a focused upgrade for everyday debugging:
Long builds and noisy framework output are noticeably easier to navigate.
The new-project flow now checks whether your chosen port is available before you submit, so port collisions surface immediately instead of as a cryptic build failure.
When you set a custom port for your application during project setup or in project settings, Brimble now checks whether the port is available on the target environment in real time. If it conflicts with another service or falls outside the allowed range, you'll see the error inline — instead of finding out twenty seconds into a failed deploy.
A small change, but it saves a build cycle every time.
The free plan is now scoped to static-site deployments. Server-side frameworks (Next.js, Nuxt, Remix, etc.) require a paid plan, with a clear upgrade path during project creation.
The free plan now has a clear, single purpose: hosting static sites. When you create a new project on the free plan, server-side frameworks (Next.js, Nuxt, Remix, SvelteKit and similar) are flagged at the project setup step with a one-click path to upgrade.
If static is what you wanted, nothing changes — your project deploys the same way it always did, on the same plan. If you need a server runtime, you'll see exactly what plan unlocks it before the deploy starts, instead of finding out after a confusing build failure.
Existing free-plan projects that are already running server-side frameworks continue to deploy without interruption.
When a deployment fails, the assistant reads your logs and project structure, explains the root cause, and can open a pull request with a proposed fix on GitHub, GitLab, or Bitbucket.
Failed deployments now come with built-in help. The assistant ingests your build logs, walks your repository's file tree, and produces a structured root-cause analysis with concrete suggestions — exactly where the error is and what to change.
On supported plans, it goes one step further and opens a pull request against your repository with the proposed fix. Auto-fix PRs are supported across GitHub, GitLab, and Bitbucket. PR generation is queued, retries on transient failures, and notifies you when the fix is ready to review — so you can keep working while it runs in the background.
A few things we built in from day one:
If you've ever stared at a 200-line stack trace at midnight, this is the feature.
If you're about to deploy Next.js, Nuxt, Remix, or another server-side framework as a static site, the dashboard warns you before the deploy starts.
The deploy configuration screen now detects when you're about to deploy a server-side framework — Next.js, Nuxt, Remix, SvelteKit — as a static site, and warns you before starting the build.
You get a clear explanation of what will and won't work in static mode, and a one-click switch to the framework's recommended deploy mode. If static is genuinely what you wanted, you can confirm and continue without leaving the screen.
This catches one of the most common deployment mistakes before it ships.
Brimble now ships its own changelog page — entries grouped by date, with proper markdown rendering for lists, links, and emphasis.
Brimble now publishes a public changelog so you can see what shipped each week without checking the dashboard for new behaviour. Entries are grouped by date, formatted with proper markdown rendering — lists, bold, links, fenced code — and organised by type (Feature, Improvement, Fix) so you can scan for what's relevant to you.
The page you're reading this on is, in fact, the page itself.
This is also the public surface for the weekly changelog automation we run internally — every Friday a new batch lands here, written for users, not for engineers.
Deployment history now links straight to the originating pull request, and the repository picker on new projects loads noticeably faster.
Two small but high-traffic improvements:
Logs from failing deployments now stream into the dashboard live, instead of arriving after the build finishes.
Failing builds now stream their logs into the dashboard in real time, so you see the error the moment it occurs. No more waiting for the build to finish before you can start debugging.
The build view stays focused on the build itself — AI debug suggestions arrive after the build settles rather than competing with the live output, so the experience is clean while it's running and helpful the moment it stops.
Pushes from non-members and viewers no longer trigger auto-deploys on team-owned projects, with a clear notification of who attempted the push.
Auto-deploys on team-owned projects are now scoped to team members with deploy permission. A push from a viewer, a non-member contributor, or a forked-PR author no longer kicks off an automatic deployment to your production environment.
When a non-permitted push arrives, the team is notified — a record lands in your activity feed and an email goes to project owners — so you can see who tried, decide whether to grant access, and run the deploy manually if you choose.
This tightens the security posture on shared projects without slowing down legitimate contributors.
Successful deployments now purge the Cloudflare edge cache automatically across every zone your project routes to, so latest changes are visible immediately.
After every successful deployment, Brimble now purges the Cloudflare edge cache for the affected hostnames automatically. Multi-zone routing is handled correctly, so projects whose domains span multiple Cloudflare zones get a coordinated purge across all of them.
The upshot: deploy a change, see it live immediately. No more refreshing in private windows to check whether the cache caught up, and no more manual purge buttons before announcing a release.
Move ownership of a project from your personal account to a team — or between teams — without recreating the project or losing its history.
Project ownership transfer is now live in the dashboard. Move a project from your personal account to a team, hand it off to another team, or transfer it to a different user — all without rebuilding the project, reattaching environment variables, or migrating custom domains.
The transfer carries over the project's deployment history, environment variables, shared secrets, custom domains, and billing context. Once accepted by the new owner, the project appears in their workspace immediately and continues serving traffic without an interruption.
Useful when projects outgrow personal accounts, when teams reorganise, or when a contractor hands off a build to a client.
Account, billing, and deployment events now appear as notifications in the dashboard, so you don't have to dig through email to know what's happening on your account.
Notifications for account, billing, and deployment events are now delivered directly in the dashboard, in addition to email. You'll see a notification when something needs your attention — a payment to retry, a deployment that finished or failed, a domain that needs DNS verification — without leaving the product or digging through your inbox.
Notifications are persistent (so you can come back to them) and grouped by project, so the panel stays scannable even on busy accounts.
See exactly what you're paying for this cycle — base plan, metered usage, and credits — with a per-line breakdown and hover tooltips.
Your billing page now shows a full breakdown of the current cycle: your base plan, metered usage broken down by resource (compute, bandwidth, storage, build minutes), and any credits or one-time adjustments. Each line has a hover tooltip explaining what's included and how the line was calculated.
The breakdown is read from the same source of truth that produces your invoice, so the numbers you see in the dashboard always match the numbers you'll be charged. No more end-of-month surprises, and a clear answer when someone on your team asks where the bandwidth bill came from.
Filter and combine conditions with a new query builder, so you can drill into deployments, projects, and logs faster.
An advanced query builder is now available for filtering across your projects and their data. Combine multiple conditions — status, branch, framework, time range, deployment author — save the views you use most often, and get to the deployment, log line, or project you need without scrolling.
Especially useful on busy accounts: pin a "failed deploys this week" view, or a "production deployments by branch" view, and they're a click away every time you open the dashboard.
Project listing, search, and pre-deployment steps are noticeably faster, especially for accounts with many projects.
We optimised how project lists and search are served, so the dashboard loads measurably faster — particularly for accounts with a long list of projects, where the difference is most noticeable.
Pre-deployment steps have also been streamlined, shaving consistent time off every deployment regardless of project size. Metrics and logs queries are now scoped per project, which keeps the dashboard responsive even on busy accounts where dozens of deployments are running concurrently.
Configure the port your app listens on directly from the dashboard, with a sensible default detected per framework.
You can now set a custom port for your application directly from the project settings. Brimble detects a sensible default port for each supported framework — Next.js, Nuxt, Express, Flask, Rails, and the rest — so most projects continue to work with zero configuration.
If your app needs a non-standard port (a specific compliance requirement, a multi-process setup, or just a personal preference), you can now configure it without editing build commands or wrapping your start script.
Build minutes are now metered separately for personal accounts and teams, with team-aware crediting and a clear cycle reset.
Build minutes are now tracked as a first-class part of your plan, with separate balances for your personal account and any team you belong to. Team-owned projects draw from the team's shared pool, personal projects draw from yours, and crediting is enforced at the team level — so multiple members building in parallel always see a consistent count.
Your remaining minutes, the date the next cycle resets, and which account or team owns the balance are now surfaced in your overview so you always know where you stand. If you're getting close to your monthly cap, you'll see it before you hit it, with a path to upgrade or top up directly from the same screen.
Settle a past-due invoice directly from the dashboard, without changing your payment method or waiting for the next retry.
If an invoice fails to charge — expired card, network blip, anything — you can now pay it directly from the billing page with a single action. No need to update your payment method, contact support, or wait for the automatic retry cycle to come around.
While an invoice is outstanding, plan changes and other billing-sensitive actions are blocked with a clear message that explains exactly what's owed and links straight to the payment action. As soon as the invoice is settled, everything unlocks immediately — no manual intervention from anyone needed.
Builds and dashboard pages are noticeably faster across the board, with tighter health checks and lower CPU usage during deploys.
A broad performance pass across builds and the dashboard:
Most accounts will notice the difference on their next deploy.
Enable or disable the build cache on a per-project basis from the project settings.
Build cache is now a per-project setting in your project's build configuration. Leave it on (the default) and incremental deploys reuse the previous build's artefacts where possible — significantly faster for most projects. Turn it off when you want a clean build from scratch, for example after a major dependency upgrade or when chasing down a build-environment issue.
No more pushing empty commits or renaming files just to force a fresh deploy.
Connect a GitHub repository to an existing project — or disconnect one — without deleting and recreating the project.
You can now link a GitHub repository to an existing project, or unlink it, directly from the project settings. Until now, moving a project to a new repository meant recreating the project from scratch and reattaching environment variables and domains by hand.
Now it's a single action: move a project to a new repository, switch from a fork to upstream after a contributor merges your work, or temporarily detach a repo while you reorganise your code — all without losing the project's deployment history, environment variables, or custom domains.
Define a secret once and reference it from any of your projects, instead of pasting the same value into every environment.
Shared secrets let you define a value once at the account or team level and reference it from any of your projects. Update the source value and every project that references it picks up the new value on next deploy — no more updating five projects every time you rotate an API key.
This also makes onboarding new projects faster: spin up a new app and pull in your team's standard secrets (database URLs, third-party API keys, observability tokens) with a couple of clicks instead of pasting values from a password manager.
For security, the secrets management page is masked from analytics, and what we used to call environment variables is now consistently labelled as secrets across the dashboard, so the surface area you protect is clearly delineated.
Trigger deployments only when specific paths in your repository change, with first-class monorepo support.
You can now configure watch paths on your project — glob patterns that determine which file changes should trigger a new deployment. Push a change outside the watch path and the deploy is skipped; push inside it and we build as usual.
Monorepo path detection is built in, so if your project lives in a subdirectory we automatically scope watch paths to that subdirectory. A change to your apps/web codebase won't rebuild your apps/api deployment, and vice versa.
Watch paths are particularly useful for monorepos, documentation sites that live alongside application code, and projects that share a repository with infrastructure or tooling you don't want triggering builds.
Search across your custom domains from the domains list, instead of scrolling through every entry.
The domains list now has built-in search. Type a domain or subdomain and the list filters live as you type, so finding a specific record on accounts with dozens or hundreds of custom domains is no longer a scroll-marathon.
The dashboard also now defaults to light mode for new accounts — existing accounts keep whatever you had set, and you can switch in your appearance settings either way.
Search across deployment history logs, download logs as files, and see request log trends — with cleaner formatting and configurable retention.
A focused upgrade to the logs experience, mostly aimed at making debugging faster:
Brimble now supports GitLab and Bitbucket repositories alongside GitHub, with full end-to-end deployments, webhooks, and account connection.
Brimble is now Git-host-agnostic. You can connect GitLab and Bitbucket accounts alongside GitHub, and deploy from any of them with the same workflow.
If you've been waiting to bring a GitLab or Bitbucket-hosted project to Brimble — or you've been juggling multiple Git providers across teams — you can now consolidate them in the same dashboard.
Register a passkey and skip passwords entirely. Hardened end to end against replay and phishing.
Passkey authentication is now supported on Brimble. Register a passkey from your security settings and you can sign in with Touch ID, Face ID, Windows Hello, or any FIDO2-compatible authenticator — no password to type, no codes to copy.
Passkeys are bound to your device and your domain, which makes them resistant to phishing by design. You can register multiple passkeys per account — one on your laptop, one on your phone, a hardware key for the team admin — and combine them with two-factor authentication if you want a second layer.
Protect your account with a TOTP-based second factor on top of your password, with prompts on sign-in and sensitive actions.
You can now enable two-factor authentication on your account from the security settings. Scan the QR code with any standard authenticator app (1Password, Google Authenticator, Authy, etc.), confirm the code, and 2FA is on. Recovery codes are generated at setup so you don't lose access if your authenticator device is unavailable.
Once enabled, you'll be prompted for a code on sign-in and on sensitive actions like changing your password or rotating API keys. The challenge screen closes itself as soon as the code is verified, so you spend less time bouncing between windows.
Teams with internal security or compliance requirements can now point at Brimble with confidence.
Deployment status updates now arrive in the dashboard live, so you see every state change the moment it happens.
Deployment status changes — queued, building, ready, failed — now stream into the dashboard in real time over a persistent connection. Open a project, push a commit, and you'll watch the deployment move through each phase live, without refreshing.
The same real-time channel powers two-factor challenge dismissal and notification delivery, so the dashboard feels more responsive across the board, not just on the deploys page.
Brimble's own web analytics — built in-house, included with every project. Traffic, top pages, referrers, geography, and Core Web Vitals, with a one-line tracking snippet and zero third-party dependencies.
Brimble now ships its own built-in web analytics for your deployed applications. This is a fully in-house product — no Google Analytics, no third-party SaaS, no separate account to manage. Drop a single tracking snippet into your app — copy it from the new snippet modal in the dashboard — and you'll see:
The tracking script is lightweight, privacy-respecting by default, and runs alongside your app on the same edge — so analytics stay fast even on slower networks. Because it's first-party to your deployment, the data is yours, the script can't be blocked as a third-party tracker, and there's no extra bill arriving from another vendor at the end of the month.
If you've been bolting on Google Analytics, Plausible, or Fathom out of habit, you can skip the integration step entirely and use what's already in your dashboard.
Project pages now load measurably faster, with parallel data fetching and a leaner landing page.
A focused performance pass on the dashboard. Project and analytics pages now fetch their data in parallel rather than sequentially, so opening a project shows you the most important data immediately while the rest streams in. The public landing page was trimmed and re-tuned for first paint, especially on mobile and slower networks.
The result: noticeably snappier navigation across the dashboard, and a faster experience for visitors landing on the marketing site.
If a payment fails, your existing deployments keep running and you can still ship updates while you settle the invoice.
We added explicit grace handling for accounts in past-due status. If your latest invoice didn't charge — for any reason — your existing deployments continue serving traffic, and you can still push deployments while the invoice is outstanding.
The dashboard surfaces a clear past-due banner and tooltip on every project, with a direct link to settle the invoice. As soon as the payment clears, the banner disappears automatically. No more racing the clock to update a card to keep production alive.
Project details and authentication pages got a visual refresh, and the dashboard now refreshes cached data immediately when you take an action.
A round of dashboard polish:
The pre-build phase — repository fetch, dependency resolution, framework detection — is now noticeably quicker on every deploy.
We shaved consistent time off the pre-build phase that runs before every deployment: faster repository fetch, smarter caching of framework detection results, and improved handling of GitHub account metadata. The end-to-end deploy time is shorter as a result, particularly for projects with many dependencies or large repositories.
No configuration needed — it applies to your next deploy automatically.
Spin up a managed database alongside your apps, with daily backups and persistent disk configuration available from project settings.
Database projects on Brimble now ship with first-class backup and persistent-disk configuration. From the project settings, you can:
Managed databases live in the same project list as your apps, share environment variables and shared secrets, and bill into the same usage breakdown — no separate console, no separate invoice.
Search availability, buy a domain, and attach it to a project in a single linear path — without leaving the dashboard or jumping between tabs.
The domain purchase flow has been tightened end to end. From the project's domains tab, you can now search availability across supported TLDs, see live pricing, complete the purchase, and attach the new domain to your project — all in one linear path.
A few specific improvements:
.com, .io, .dev, .app, and the rest without flipping between pages.If you've been buying domains elsewhere and connecting them by hand, the in-dashboard flow is now fast enough to be the default.
Brimble now hosts Model Context Protocol servers — browse the Smithery registry, deploy with a click, and connect them to your agents.
MCP servers are now a first-class project type on Brimble. Browse the Smithery registry directly from the dashboard, filter by category or capability, and deploy a server with a click — no manual Docker, no environment juggling.
Once live, your MCP server gets a public endpoint, deployment logs, and the same observability you already use for your apps. Connect it to Claude, Cursor, or any other MCP-aware client and start calling tools immediately.
If you're building agent-driven products, this is the fastest way to put a tool surface in front of your users.
Every invoice now has a hosted page you can open, share with finance, or send to your accountant — no PDF wrangling required.
Each invoice on your billing history now exposes a hosted invoice page. Open it for a printable view, forward the link to your finance team, or attach it to your accounting tool of choice.
The hosted page includes the full breakdown — base plan, metered usage, taxes, credits — and a payment action if the invoice is still outstanding.
Spend little to no time on DevOps and more time building. Super efficient way to host & scale your web app.
