Changelog

Billing

• The per-project usage breakdown now accounts for regional pricing, so it matches what you're invoiced.
• Upgrading your plan is no longer at risk of being undone while the upgrade's payment is still pending.
• Accounts funded from the wallet can edit their spending limit without adding a card.
• The dashboard shows your new plan as soon as you subscribe or change plan.

Teams

• When a team's subscription ends, the team becomes read-only instead of continuing to deploy. You can still view everything, manage billing, remove members or delete the team. Renewing the subscription makes it active again.
• Members get an email when their role in a team changes, saying what it changed from and to, and who changed it.
• When a member leaves a team, the team projects they owned are handed to the team creator.

Config as code (brimble.toml)

• Plans no longer show changes that aren't real, such as reordered lists, and approvals no longer get stuck.
• An apply interrupted by a restart on our side now picks up where it left off, instead of blocking the environment.
• Services that set build.dockerfile are built with that Dockerfile.
• Databases defined in 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.

Accounts and API

• Disabled accounts see a clear notice with options to report a problem or log out, and can still open a support ticket.
• API key rate limits now follow your plan when you upgrade or downgrade.
• Cron jobs need the Developer plan or above. Enabling cron on another plan now explains this, instead of deploying in a way that can't run the schedule.

Domains

• When www is attached to a root domain, its DNS record is listed right next to the root's.
• Domain search shows results as you type.
• Paying for a domain with crypto works again.

Logs and deployments

• Deployment history loads for projects deployed from a Docker image.
• Build logs longer than 1,000 lines show all the way to the end, and long logs load faster.
• The deployment history date filter uses your local day, so deploys made after midnight UTC aren't hidden if you're west of UTC.
• A project's status in the dashboard updates as soon as it changes.

Object storage

• Lagos buckets honour If-None-Match: * on uploads, so an upload that shouldn't overwrite an existing object is rejected with 412 Precondition Failed.
• Fixed an issue on October 23 that made the Lagos storage endpoint return 502 errors.

What changed

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.

Builds

• Next.js apps in monorepos keep their build cache between builds, so repeat builds are faster.
• Time spent waiting for your project's previous build to finish no longer counts toward the build timeout.
• Bun projects using the newer bun.lock format (lockfile version 2) install correctly.
• A build that runs out of memory now fails with an error instead of hanging.
• A build that gets interrupted by maintenance on our side is marked as failed, instead of staying in progress forever.

Fixes

• An app that restarts while its deploy is still finishing keeps its private network connections, instead of timing out when it calls other services.
• Switching a project to a static site removes its old app containers.

What changed

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.

What changed

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.

Fixes

• Switching a database between public and private takes effect reliably.
• Network charts show data for databases and high-availability projects again.
• Large MongoDB backups no longer fail by running out of memory.
• Backing up an empty Dragonfly database succeeds instead of failing.

What changed

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.

How far back you can go

The deployment just before the live one can always be rolled back. Beyond that, it depends on your plan:

• Free: deployments from the last day
• Hacker: the last 7 days
• Developer and Team: the last 20 days

Good to know

• Rollbacks restore your app's code and configuration only. Databases, volumes and other external data are not rolled back.
• Static sites and projects deployed from a Docker image can't be rolled back yet. Redeploy them from source instead.
• A stopped project needs to be started before it can be rolled back.
• Rolling back needs the same permission as deploying.

What changed

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:

• requests and errors, with the error rate (4xx and 5xx responses)
• average, P95 and P99 response times
• how much data the route sent

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.

Good to know

Route activity is built from your project's request logs, so it covers traffic that reaches your app through Brimble.

What changed

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.

Good to know

• Custom domains aren't copied, because a domain can only point at one project. You'll see which ones were left out.
• The copy counts toward your plan's project limit, and the target region needs room for it.
• Duplicating needs permission to create projects in the target environment.
• You can also duplicate a project from the API.

What changed

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:

• each affected package, its version and the file it came from
• the version that fixes it
• the advisory, with a link to its details

Upgrade the package, push again, and the deploy goes through.

What blocks a deploy

• npm: only packages you depend on directly in 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.
• Other ecosystems: their lockfiles don't say which packages are direct, so any critically vulnerable package blocks the deploy.

Good to know

• Only advisories rated critical are checked.
• If the scan itself fails or takes too long, your deploy continues. It never blocks a deploy because of a problem on our side.

What changed

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.

Good to know

• Only turn this on for services that are meant to be shared. Any service in any of your environments will be able to call it.
• Static sites don't have an internal address, so the setting isn't available for them.
• You can also set it from the API.

What changed

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-url

Hard 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.

Good to know

• Anyone with the link can open it while the sandbox is running, so only share it with people you trust.
• The sandbox must be running. Paused or stopped sandboxes don't serve their preview URL.
• Only the sandbox's owner, or teammates who can view it, can request a link.

What changed

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.

What changed

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

• Upgrading your plan takes effect immediately and is invoiced right away, instead of at your next renewal.
• If you'd scheduled a cancellation and then change plan, the cancellation is lifted.
• Static sites no longer accrue compute charges.
• The onboarding checklist now includes adding a card or funding your wallet.

Domains

• If a domain's DNS doesn't point to Brimble yet, its owner gets a reminder every two days until it does.

Environment variables

• Editing several variables and saving once now saves all of them.
• Pasting a database connection string that uses TLS shows a reminder that your app also needs the certificate.

Teams

• Members invited to take over a team can accept the ownership transfer. The Accept button was disabled for them before.

Databases

• The Redis workbench works without choosing a database name first.
• The Postgres workbench limits itself to 10 connections, so it can't crowd out your app.

Networking

• Dedicated outbound IPs stay connected more reliably, including for large requests.

Dashboard

• Project tabs that don't fit on screen move into a menu instead of overflowing.

What changed

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.

• Message: the full line, wrapped so nothing is cut off, with terminal color codes removed so it reads cleanly.
• Fields: if your app logs JSON, each field is shown as its own row.
• Source: the output stream (stdout or stderr), the instance that wrote it, the service, its type, your project ID and the exact timestamp.

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.

What changed

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.

Good to know

• The key is shown masked on screen. The full key only goes into what you copy.
• You can manage or rotate your keys any time under Settings → API keys.

What changed

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/brimble

Or with the install script on macOS and Linux:

curl -fsSL https://brimble-cli.t3.tigrisfiles.io/install.sh | sh

Windows 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 deploy

In 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.

Learn more

The full guide is at paper.brimble.io/cli/overview.

What changed

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.

Fixes

• Redeploying a commit that was already built no longer fails looking for a missing image.
• Apps built on Alpine Linux resolve private service names correctly.
• Apps with a volume mount the right storage when they start.
• Deploys are no longer held back when a server's reserved capacity is full but there's room to run.
• Old copies of your app are cleaned up on every server that ran a previous deploy, not just the latest one.
• A deploy no longer aborts on start for web services that don't define an environment name.
• Server health is judged on a five-minute average, so a short spike no longer marks a healthy server as busy.

What changed

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.

Also in this release

Redeploying a stopped project now tells you to start it first, instead of queueing a deploy that can't run.

What changed

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.

Pricing

One project with preview collaboration is included. Each additional project is $6 per month.

Learn more

See the preview collaboration guide in the docs at paper.brimble.io.

What changed

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.

Fixes

• Redeploying a preview now redeploys that preview, instead of accidentally targeting production.
• Previews stay marked Active after a successful deploy.
• Previews are routed correctly even when the production app runs as multiple replicas.

What changed

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.

Also in this release

Validation errors from the API now use the same error format as every other error, so client code only has to handle one shape.

What changed

Notification settings now group Brimble's emails into four categories, each with its own switch:

• Billing & usage: payments, usage limits, domain renewals and trials.
• Project activity & alerts: deployments, databases, domains and alert notifications.
• New repositories: when a new repo from your Git provider is ready to import.
• Product updates: changelog, streaks, quests and rewards.

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.

One-click unsubscribe

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.

Good to know

• You can jump straight to these settings at /settings/notifications in the dashboard.

What changed

We spent a lot of this cycle on the parts of managed databases you shouldn't have to think about.

Reliability

• Busy MongoDB databases handle many more open connections and files without errors.
• Health checks are more accurate, so a healthy database isn't restarted by mistake.
• Refreshing a database reliably brings it back if it ever stops.
• Connection handling copes better with sudden spikes in traffic.

Engines

• Dragonfly sizes its threads from its memory limit and authenticates correctly with just a password.
• Redis and Dragonfly keep TLS on their private address when TLS is on.
• RabbitMQ starts reliably on the first try.
• Postgres restores and template-based setups were fixed, and dropping a database user works again.
• MongoDB HA waits for every member before forming the cluster, and password rotation keeps every member in sync.

What changed

A roundup of fixes that shipped between mid-September and mid-October.

Analytics and observability

• Web analytics charts no longer show a row of zeros before your real data, and month views are populated again. Time buckets now line up with your timezone.
• Alert evaluation was fixed, so metric alerts fire when they should.
• Database Insights work for databases with TLS turned on.

Deploys and projects

• Static assets such as fonts, images and scripts can now be loaded from other origins, which fixes broken fonts and icons when your site is embedded or served through a CDN.
• While a deploy is in progress, visitors see the "deploying" page instead of a raw error.
• Static file deploys and prestart commands were fixed.
• Autoscaling groups were fixed for projects that use them.
• Deleting a project can now remove its attached volume too.

Dashboard

• Switching environments reloads the project tabs, and same-named projects in different environments always open the right one.
• Saving several edited variables happens from a single save bar, and revealed secrets are no longer marked as edited.
• Domains and projects load faster, and Git branch search finds branches in large repositories.
• Deletes ask for confirmation, and a crash screen now includes a link to report the problem.

What changed

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:

• The newest push wins. If you push twice quickly, the older build is marked Replaced, not Failed, and only the newest one goes live.
• A failed deploy can't take you offline. If a replacement deployment fails, your current live version keeps serving traffic exactly as before.
• Cancelled deploys stay cancelled. A build you cancelled, or one that was superseded, can't change your live routing on its way out.
• Nothing is lost in the queue. Deploys waiting their turn always go through, even during maintenance on our side.

Also improved

• Your personal build concurrency now takes priority over your plan's default on personal projects.
• Before redeploying a Git project, Brimble checks the repository connection is still valid and tells you clearly if it isn't.
• Docker image deployments made through the API or MCP now deploy correctly.

What changed

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:

• Start and stop a service.
• Move a project to another environment.
• Turn dedicated outbound IPs on or off, and read the addresses to allowlist.
• Run a command inside a running service and get the output back.

Good to know

• Agents act through an API key, so team roles and key permissions apply exactly as they do for people.
• Docker image deployments started from an agent now deploy correctly.
• Agent suggestions in the dashboard stay visible, and are disabled with a clear hint if no API key is set up yet.

What changed

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.

When to use it

• You've lost a device, or it's been stolen.
• You signed in on a shared or public computer and forgot to log out.
• You've changed your password or two-factor settings and want a clean slate.

Also in this release

• New accounts can add a first and last name at sign-up, and welcome emails greet you by username if you skip it.
• Expired sign-in links from your identity provider now return a clear "please try again" message instead of an error page.

What changed

How long we keep your logs is now enforced consistently per account, based on your plan:

• Free: 7 days
• Hacker: 30 days
• Developer and Team: 90 days

Runtime, build and request logs all follow the same rule, so you always know how far back you can look.

Also improved

• Complete request logs. The request log view shows all of your project's traffic again.
• Longer-lived connections. Idle connections now stay open for up to 5 minutes, which fixes timeouts on slow uploads, long-polling and streaming responses.
• Metrics for CPU and memory reflect the version of your app that's currently live.

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.

What changed

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.

Also improved

• Nameserver status is more accurate for brand-new domains.
• Fixed a redirect issue on some custom domains, and domains now load correctly on the project page.

What changed

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:

• App crashing. Your app restarted 3 or more times within 30 minutes.
• Repeated deployment failures. Your last 3 deployments all failed.
• Unreachable private dependency. Your app points at an internal address or linked service that can't be reached.
• Broken environment reference. A variable references a project, database or bucket that no longer exists.
• Database backups failing. Scheduled backups for a database aren't succeeding.
• Database storage almost full. A database has used more than 85% of its disk.

Good to know

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.

What changed

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 DNS is managed elsewhere

If your domain still uses our previous records, it keeps working and there's no downtime. To get the failover protection, update your records:

• Subdomains: a CNAME to gateway.brimble.app.
• Root domain: an ALIAS/ANAME/CNAME to gateway.brimble.app, or move your nameservers to Brimble if your provider only allows A records on the root.
• On Cloudflare, keep these records DNS only (grey cloud).

Domains already on Brimble DNS were updated automatically. Owners of domains that need a manual change are being notified by email.

Also in this release

• Root CNAMEs on Brimble DNS. Root records that point somewhere by name are now flattened to IP addresses, so your root domain can follow a target that changes its IPs.
• Automatic DNS adoption. If you add a domain and later switch its nameservers to Brimble, we detect it and enable DNS management automatically. No need to remove and re-add the domain.
• Long TXT records such as DKIM keys are now split correctly, so they verify with mail providers.
• Faster certificates. Newly connected domains get their HTTPS certificate faster and more reliably, including behind proxies and CDNs.

What changed

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.

How it handles the tricky parts

• Domains. Brimble subdomains are recreated with a suffix, so 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.
• Databases. Cloned databases get their own fresh credentials. A staging database can never accidentally share a password with production.
• Connection pooling. Pooling settings are only carried over for databases that use them.
• Static sites clone like any other project.
• Speed. Projects are cloned in parallel and deployed only after every reference has been remapped, so the new environment comes up consistent instead of half-wired.

How to use it

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.

What changed

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.

Good to know

• The email tells you the date your build minutes reset.
• Like all billing emails, it follows your Billing & usage email preference.

What changed

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.

Also in this release

• Itemised pricing. The plan breakdown shows seats and concurrent build add-ons as separate lines, so it's clear what you're paying for.
• Easier team creation. Creating a team is now a single step with just a team name, and it's noticeably faster.
• Reactivating a lapsed team. If a team's subscription ended, you can resubscribe with the same name and pick up where you left off.
• Developer plan trial. The Developer plan trial is now 7 days.

What changed

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:

• Services: type (web, worker, static, MCP), CPU and memory, build and start commands, Dockerfile, watch paths, health checks, replicas and autoscaling, cron schedules, persistent volumes and mounted files.
• Variables: plain values and references such as {{@db.PRIVATE_CONNECTION_STRING}}.
• Networking: domains, redirects, rate limits, caching, security headers and firewall rules.
• Databases: engine, version, disk, TLS, connection pooling, high availability and backup schedules with retention.
• Buckets: region, CORS and lifecycle rules.
• Observability: alert rules and log drains.
• Environments: per-environment overrides, so staging can use less memory, and previews can get their own settings.

Safe by default

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.

How to get started

• Open a project and use Generate brimble.toml to export its current settings into a ready-to-commit file.
• Use Preview a brimble.toml to paste a file and see exactly what it would change before you push it.
• Settings controlled by the file show a Managed by brimble.toml badge in the dashboard, so nobody edits them in two places.
• Removing a domain from the file never detaches it. Destructive cleanup stays a deliberate action in the dashboard.

What changed

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.

Also in this release

• Smaller minimum sizes. The smallest service is now 0.2 vCPU and 0.5 GB memory, the same across every service type, so small APIs and workers cost less.
• Usage by region. Detailed usage insights break down spend by region, and the downloadable cost analysis PDF now includes the full rate card and the regions you used.
• Clearer region availability. Region descriptions were refreshed, and regions that are full are marked unavailable, rather than letting a deploy start and then fail for lack of capacity.
• More time to settle unpaid invoices. Projects on unpaid accounts are now kept for 30 days before removal.

What changed

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:

• Card (USD), as before.
• Local payment methods, including local currency, mobile money, bank transfer and crypto, for when an international card isn't practical. You pay in your currency, and your balance is credited in USD.

How it works

• Go to Billing → Credits to see your balance, add credit and browse transactions.
• Choose whether subscriptions are paid wallet first or card first. With wallet first, a short balance falls back to your saved card if you have one.
• If a card payment fails on an open invoice, the wallet is used automatically when it has enough balance.
• Team wallets are separate from personal ones, and only people allowed to manage billing can use them.
• You can now create or reactivate a team and pay for it entirely from credit, with no card on file.
• Wallet activity, such as top-ups landing or a payment being taken, shows up in your in-app notifications.

What changed

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.

Good to know

• Public object URLs are now served from objects.brimble.io.
• Browsing large buckets in the dashboard is smoother, and a bucket name that's already taken is flagged as you create it.
• Lagos storage is priced with a regional rate. The estimate in the dashboard shows the exact cost.

What changed

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.

The built-in roles

• Creator. Full access, including billing, ownership transfer and deleting the team.
• Administrator. Full access to every environment and team management, but can't change ownership or billing.
• Member. Create, deploy and edit inside assigned environments. Can't manage the team or delete projects.
• Viewer. Read-only inside assigned environments.

Good to know

• API keys respect the same rules: a key can only do what its owner's team role allows.
• Billing follows the same roles, so you decide who can see invoices and change payment methods.
• People invited by email now land on sign-up instead of log-in if they don't have an account yet, get the team's default environment when they accept, and have their email prefilled from the invite link.

What changed

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:

• Brimble (default). Backups are stored by Brimble and pruned automatically after your retention period.
• Your Brimble bucket. Send backups to one of your own storage buckets, where you control them completely.
• External S3-compatible storage. Point backups at AWS S3, Cloudflare R2, Tigris or any S3-compatible endpoint. Brimble checks the credentials can reach the bucket before saving, and stores them encrypted. They're never shown again.

Schedules, history and restores

• Automatic backup schedules now run in your timezone, so "2 AM" means 2 AM where you are, not in UTC.
• You can now delete individual backups from the history list.
• Restores show up in the same history as backups, with live status, so you can follow a restore from start to finish.
• If your database has gone a while without a backup, you'll get a reminder email, sent once rather than on repeat.

Reliability fixes

• ClickHouse backups now include every database on the server, and the dumps restore cleanly.
• MongoDB backups include time-series collections.
• Redis and Dragonfly backups work over TLS when your database's private address serves TLS.
• Backups for a single database run one at a time, so a slow backup can't pile up behind itself.

Good to know

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.

What changed

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.

Good to know

• Internal addresses include the environment where needed, so staging services talk to staging services and production to production.
• Databases can be linked to projects by ID, and the link stays correct even if you rename the database.
• When you link apps to a high-availability database, each member is reachable on its own private address.

What changed

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.

Running one-off 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".

Good to know

• The terminal connects to the healthy instance currently serving traffic. If a deploy is still coming up, it attaches to the new build so you can inspect it.
• Running commands requires permission to execute commands on the project. Custom roles can grant or withhold it.
• Sessions expire after a fixed time, so a forgotten tab doesn't stay open forever.
• Not available for static sites, databases or MCP projects.
• Error messages for dropped or expired sessions are now plain English, and the sandbox terminal got the same reliability fixes.

What changed

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.

How to use it

• Open your project's Networking settings and enable Dedicated outbound IPs.
• Copy the listed addresses into the allowlist of the service you're connecting to.
• Turn it off at any time. Traffic goes back to the shared path immediately.

Good to know

• Available on the Developer and Team plans for $5 per project per month, added to your regular monthly invoice. Turning it on or off mid-month is prorated.
• The first pool covers our European regions. Other regions will follow.
• The addresses are reserved for Brimble projects that use this feature in that region. They aren't exclusive to a single account.
• This controls outbound traffic only. It doesn't change the IP your domain resolves to.
• You can also turn it on from your AI agent through the Brimble MCP server.

What changed

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.

How to use it

• Open your domain, go to Email forwarding, and add an alias with a destination address.
• New aliases show as Setting up while DNS propagates, then switch to Active.
• Use Send test on an active alias to confirm mail arrives where you expect.
• You can change an alias's destination or delete it at any time.

Good to know

• Email forwarding costs $0.75 per domain per month and needs a payment method on file.
• The domain's nameservers must point at Brimble. If they don't, the page explains how to switch.
• Each address forwards exactly as written. There's no catch-all.
• To keep the service healthy, there's a daily limit on new aliases. If you hit it, you'll get an email, and creating more is unlocked again the next day (UTC).

What changed

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."

Good to know

• Recommendations refresh every 12 hours per database, so opening the tab repeatedly doesn't cost anything or change the advice mid-investigation.
• Postgres databases now always have pg_stat_statements enabled, which gives the recommendations real per-query data to work from.
• Disk throughput (IOPS) metrics were reworked so read and write pressure show up accurately in the charts the recommendations are based on.

What changed

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.

How to set it up

• Open New database, pick MongoDB or Postgres, and switch on High availability.
• Choose a primary region and two secondary regions. You can reuse a region twice, but all three members can't sit in the same region. That's the point of HA.
• The form checks live capacity per region. If a region can't fit another member at your chosen size, the create button tells you before you submit.
• Public MongoDB clusters need TLS turned on. For Postgres, TLS is optional.

Good to know

• HA is available on the Developer and Team plans.
• CPU, memory and storage are billed per member, so a cluster costs three times the single-node price. The estimate in the form shows the full amount.
• HA is chosen when you create the database. Existing single-node databases can't be converted in place yet.
• Each member gets its own private address, so linked apps can reach the cluster over the private network, and password rotations are applied to every member.

What changed

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.

Also in this release

• Resizing a database now sends you an in-app notification when the new CPU, memory or storage size is live.
• Fixed a rare issue that could make creating a database fail in busy regions.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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:

• S3-compatible API. Standard GET, PUT, DELETE, and multipart upload operations work out of the box with any S3 client or SDK. No proprietary API to learn.
• CORS, lifecycle, and access controls. Configure cross-origin rules, automatic object expiration, and bucket-level access policies directly from the dashboard or API.
• Multiple storage providers. Choose between Cloudflare R2 and Tigris as your backing provider when you create a bucket. Each has different performance and pricing characteristics — pick the one that fits your workload.
• Plan-based limits. Bucket counts and storage quotas are tied to your plan, with clear 402 responses when you hit a ceiling. Upgrade paths are surfaced in the dashboard.
• Folder creation and bulk upload. Organize objects into folders and upload entire directories in one batch.

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.

What changed

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.

What changed

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.

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.

What changed

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.

What changed

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.

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.

What changed

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:

• Auto-destroy timers. Set a TTL when you create the sandbox and it shuts itself down at the deadline. No lingering containers, no surprise charges.
• One-shot mode. Run a single task and the sandbox tears down the moment it exits. Perfect for short-lived jobs and one-off scripts.
• Outbound network control. Block outbound network access with a single flag for sandboxes that should be fully isolated, or leave it open for sandboxes that need the network.
• Real-time status and messaging. Watch the sandbox provision, run, and exit live in the dashboard, with notifications for state changes.

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.

What changed

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.

What changed

A pair of sandbox usability wins:

• Bulk file upload. Upload many files at once into a running sandbox from the dashboard — pick a folder, watch the progress, and they all land in the sandbox filesystem in a single batch.
• Faster provisioning. Sandbox provisioning is significantly quicker this week, particularly for templates with pre-warmed images. Combined with reduced health-check times, your sandbox is ready to use much sooner after you hit create.

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.

What changed

Every sandbox now has an interactive terminal you can open directly from the dashboard. A few details that make it actually usable:

• Persistent sessions. Reload the page, close the tab, come back tomorrow — your terminal session is still there, with full scrollback and the same working directory you left it in.
• Working directory streaming. As you cd around, the terminal UI shows your resolved current directory in real time, so you always know exactly where you are.
• Streaming exec and run-code. Behind the scenes, terminal commands and code execution use server-side streaming, so output appears the moment the sandbox produces it — no buffering delay.

What changed

Sandboxes are now stateful when you want them to be. The new capabilities:

• Pause and resume. Hit pause on a running sandbox and its compute is released — but the filesystem, environment, and process state stay around. Resume later and pick up where you left off. Useful for sandboxes you want to come back to without paying compute while idle.
• Snapshots. Capture a running sandbox at any point and save it as a snapshot. Spin up a new sandbox from that snapshot to clone the exact state, or roll back to an earlier snapshot if a change went sideways. Snapshots are scheduled automatically alongside any manual ones you take.
• Persistent volumes. Sandboxes can mount a persistent volume that survives every pause, resume, and restart. The same volume model used for managed databases now powers sandbox storage.

Fire-and-forget ephemeral sandboxes still work exactly as they did last week — persistence is opt-in.

What changed

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:

• Staging environments that should be reachable for the team and for QA, but not crawled or indexed.
• Pre-launch previews you want to share with investors, beta testers, or clients before going public.
• Internal tools where you want a low-friction gate without standing up a real auth system.

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.

What changed

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:

• Slider ranges are scoped to what your plan allows, so you can see exactly what's possible before submitting.
• Defaults are set to sensible values for each detected framework, so most projects deploy with no manual tuning.
• You can revisit the same sliders from project settings later — increasing or decreasing resources takes effect on the next deploy.

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.

What changed

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.

What changed

Workspace admins can now require all team members to have two-factor authentication enabled. Flip the switch in workspace security settings and:

• Members without 2FA see a non-dismissible setup modal when they next open the workspace. They can scan a QR code, confirm the prompt, and save recovery codes — all without leaving the dashboard. No backdoor, no skip option until 2FA is set up.
• Workspace actions are gated until 2FA is enabled. Members can still see they're part of the workspace, but can't deploy, manage domains, or take other actions until the requirement is satisfied.
• Admins can monitor compliance at a glance from the workspace member list, with an indicator for who is enrolled and who is still pending.

When combined with step-up 2FA for destructive actions (shipped last week), it gives teams a clear story to tell their security reviewers.

What changed

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.

What changed

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.

What changed

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:

• Adding a new card from the billing page or from the purchase modal.
• Domain marketplace purchases that go through the new card.
• Subscription upgrades and renewals that hit a 3DS challenge.

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.

What changed

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.

What changed

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:

• Faster, steadier name resolution. Visitors hitting your domain see lower and more consistent DNS lookup times.
• No single point of failure. If one region degrades, the next query goes to a healthy one — automatic, sub-second failover.
• Nothing to do on your end. Existing DNS records, custom nameservers, and TLD coverage are unchanged. Same dashboard, same controls.

Quiet under the hood, but it's the kind of change you only notice when something doesn't go wrong.

What changed

A round of dashboard polish focused on perceived speed and accessibility:

• Snappier navigation. Workspace lookups are deduplicated across pages, heavy UI chrome is lazy-loaded, and the route progress indicator was swapped for a lighter implementation. Net result: less work on every page change, faster perceived load times.
• Better loading skeletons. Each route now has a pending skeleton that matches the actual layout it's about to render, instead of a generic placeholder — so the dashboard feels more stable while data is loading.
• Keyboard-accessible dropdowns. Every dropdown menu in the dashboard can now be opened, navigated, and selected with the keyboard — Tab, arrow keys, Enter, Escape — for users who don't (or can't) use a mouse.

What changed

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:

• Real-time provisioning signals. The dashboard shows live status as the database goes from requested to provisioned — no polling, no manual refresh.
• Observability included on free plan. Connection counts, query latency, and resource usage are visible during the trial, so you can actually evaluate performance before committing.
• Trial-end automation. As your trial winds down, you'll see banners and emails about the upcoming end date with a one-click upgrade if you want to keep the database alive. If you let it expire, your data is preserved for a grace period before deletion, with a final reminder before anything is removed.
• Lifecycle automation. Welcome message on trial start, in-product notifications throughout, clean shutdown at the end.

What changed

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:

• Lower latency in Asia. Round-trip times for users in Asia-Pacific are noticeably shorter.
• More headroom for traffic peaks. Projects with audiences concentrated in Asia get dedicated regional capacity.
• Same automatic routing. Brimble already routes each request to your closest region — adding Asia just makes "closest" closer for a big slice of the world. No configuration needed.

Combined with our European load balancer in Frankfurt, your projects now have proper coverage across Europe and Asia by default.

What changed

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.

What changed

The build log viewer in the dashboard got a focused upgrade for everyday debugging:

• Phase rail. A side rail shows the build's phases (clone, install, build, deploy) and lets you jump to the start of any phase. Easy to find where things slowed down or failed.
• Robust auto-scroll. New output follows automatically as it streams, but politely pauses the moment you scroll up to read something — and resumes when you scroll back to the bottom.
• Copy-all. A single action copies the entire log to your clipboard, ready to paste into a ticket, an issue, or a chat with someone helping you debug.
• Selection-aware copy. Highlight a section first and copy will respect the selection instead of grabbing everything.

Long builds and noisy framework output are noticeably easier to navigate.

What changed

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.

What changed

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.

What changed

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:

• Cache without burning quota. Re-asking about the same failure hits cache instead of charging your AI budget, so investigating an issue is cheap.
• File-tree context. The assistant reasons about your whole project, not just the failing log line, so suggestions account for surrounding code.
• Plan-aware responses. Plans without AI access return a clear unavailable message instead of a generic error, and never accidentally consume credits.
• Disabled during active builds. The assistant is automatically suppressed while a build is running, so logs stay clean and your CPU goes to the build.
• Reasoning-model-safe output. Suggestions are normalised before validation, so the model can use its full reasoning capability without breaking schema constraints.

If you've ever stared at a 200-line stack trace at midnight, this is the feature.

What changed

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.

What changed

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.

What changed

Two small but high-traffic improvements:

• Preview PR links in deployment history. Every deployment that came from a pull request now exposes a direct link to the originating PR in your deployment history. Click through to the conversation, the diff, or the merge — without context-switching to GitHub.
• Faster repository picker. The repository list shown when creating or linking a project now loads from the top recently-pushed repos directly, so accounts with hundreds of connected repositories see results instantly instead of waiting for a full list to render.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

A broad performance pass across builds and the dashboard:

• Builds are faster. We tuned the build pipeline end to end — buildkit configuration, web service handling, build cache reuse — and added per-build CPU bounds so heavy projects don't slow down the rest of your deploys.
• Apps go live sooner. Health checks on new deployments are tighter and faster, so the time between "build finished" and "your app is serving traffic" is shorter.
• Dashboard cold-starts faster. We trimmed unnecessary work on initial page load and lazy-load analytics, so the first paint is quicker — especially on mobile and slower networks.

Most accounts will notice the difference on their next deploy.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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.

What changed

A focused upgrade to the logs experience, mostly aimed at making debugging faster:

• Search across deployment history. Find a log line from three deployments ago without leaving the dashboard.
• Download logs as a file. Pull a deploy's full output for offline analysis or to attach to a ticket.
• Trend graphs. See log volume over time and spot spikes that line up with a specific deployment.
• Request and application logs side by side. Caddy request logs are now surfaced next to your app logs, so you can correlate a failing HTTP request with the line of code that produced the error.
• Cleaner formatting. Tighter typography, search-result highlighting, and reduced visual noise make scanning long logs much easier.
• Predictable retention. Logs are now kept for a defined window per plan, so projects don't accumulate unbounded data and old deploys remain searchable for a sensible period.

What changed

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.

• Sign in with your provider account, authorise once, and your repositories appear in the connect-repository flow — public or private, personal or organisation-owned.
• Push events from your provider trigger deployments automatically. Webhook delivery is verified end to end on every push.
• Pull request previews, deploy logs, root-directory configuration, and monorepo handling work identically across all three providers, so your team's deployment experience stays consistent regardless of where the code lives.
• Disconnecting a provider revokes the access tokens cleanly, so you can rotate credentials without leaving stale grants behind.

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.

What changed

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.

What changed

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.

What changed

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.

What changed

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:

• Live and historical traffic with breakdowns by page, referrer, country, device, and browser.
• Core Web Vitals (LCP, INP, CLS) so you can spot performance regressions tied to a specific deployment.
• Time-series graphs that let you correlate traffic with the build that shipped, so you know whether a redesign moved the needle or a routing change broke a popular page.
• A snippet modal that gives you copy-paste integration code for any framework, with a sensible default for projects deployed on Brimble.

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.

What changed

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.

What changed

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.

What changed

A round of dashboard polish:

• The project details and authentication pages received a visual refresh — cleaner spacing, better-aligned dropdowns, and clearer hierarchy on dense screens.
• Project deployment icons now match the project type at a glance, so apps, databases, and MCP servers are distinguishable in the project list without opening each one.
• Cached data is invalidated immediately when you take an action, so the dashboard reflects your latest change without a manual refresh.

What changed

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.

What changed

Database projects on Brimble now ship with first-class backup and persistent-disk configuration. From the project settings, you can:

• Enable daily backups, choose how many to retain, and download a snapshot at any time.
• Configure persistent disk size and reattach it across redeploys, so your data survives every cycle without manual intervention.
• See your database project at a glance in the dashboard with a dedicated icon and a live status indicator.

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.

What changed

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:

• Live availability checks as you type, instead of waiting until you submit.
• TLD comparison side-by-side so you can pick between .com, .io, .dev, .app, and the rest without flipping between pages.
• Automatic DNS configuration on purchase — the domain is attached and propagating before you leave the screen.
• Purchased domains land directly in your domains list, ready to use on any project (or to move between projects later).

If you've been buying domains elsewhere and connecting them by hand, the in-dashboard flow is now fast enough to be the default.

What changed

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.

What changed

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.