deploybase Release Notes

Signing in from the command line works again. If it failed for you, run deploybase login once more.

You can now move your sign-in to a new email address from Profile, without writing to support. After a security check, a code goes to the new address, and your old address keeps working until you enter it. Confirming signs you out in every browser; team API keys keep working. Your old address gets a notice with a link to freeze the account if the change wasn't yours. If your team signs in through single sign-on, your address is managed there instead.

Your team's notifications carry form submissions and billing, so a new team address now has to confirm by email before anything is sent to it, and whoever reads that inbox can say they didn't ask for it. Your owners are told every time the address changes, and failed payments, security warnings and account notices always reach them as well. A member's own confirmed address works at once. Team › Notifications now shows who gets each kind of email right now.

You can now run a function on a timetable: add export const schedule = "0 * * * *" to its file and deploy to production. Its page shows the next three runs, every scheduled run with its result, each skipped slot with the reason, and a Run now button. A schedule that fails 10 runs in a row pauses itself and emails the team, and its page shows the error with Resume and a copy for your AI assistant. Times are UTC, and how often a schedule may run depends on your plan.

The dashboard is rebuilt around what you came to do. A project opens on its live site and what is left to set up. A deployment reads as a timeline with the log beside each step. When a build fails, you get the reason and the fix, often one button, plus a copy for your AI assistant. Red only means failed, and every state has a word. Every page was checked against WCAG 2.1 AA. If something fails your keyboard or screen reader, email support@deploybase.eu and it is fixed first. The web is for everyone.

A new account can sign in and look around straight away, but deploying, adding a domain, creating a form or inviting someone now waits until its email address is confirmed, and until then it gets no team mail. A banner says what is waiting and resends the link. Accounts created before 3 October are not affected. This keeps every site on deploybase tied to an address someone actually owns.

Sign out in the account menu no longer asks you to confirm. It now also ends the session with the identity provider, not only in your browser, so it can no longer be renewed. A sign-in link you copied, bookmarked or finished in another tab starts a fresh sign-in instead of failing after your password. Fixed a crafted link that could use a sign-out address to send you to another site.

Every email from deploybase now has one readable design: the thing it is about up front, then the one next step. A failed build's email names the step that failed, the reason and, when a setting would fix it, the change to make, applied in one click on the build's page. Sign-up codes, password resets and the notice that your password changed now come from deploybase too, from one address, and a reply reaches a person. If a sign-up code expires, you can now ask for a new one. Your notification settings are unchanged.

Sign-in, sign-up and every page you reach from an email or your terminal now share one calm, readable shape. Signing up asks for your email, your name and a password, with a Show button instead of typing the password twice. When your session ends, signing back in takes you to the page you were on, and the sign-in page lists what changed recently. How you sign in is unchanged.

Signing up with an address that already has an account now shows the same "Check your inbox" as a new sign-up, so nobody can use the form to find out whether someone uses deploybase. The owner of that address gets an email instead, with links to sign in or reset their password, at most once a day.

Your functions can now read your project's environment variables, so an API key no longer has to live in your repository. Each variable says where it is available: Build, Runtime or both. A Runtime variable reaches your production functions as context.env without a redeploy, and a secret only your functions need can stay out of your builds entirely. Existing variables stay build-only until you tick Runtime on the Environment page. You can also set them from your terminal with deploybase env, and AI agents get three new MCP tools that never return a value.

When ten builds in a row fail with the same error, deploys on push now pause for that project and your team gets one email, so a coding agent pushing to a repository that cannot build no longer triggers failing build after failing build. Your live site keeps serving, and deploys you start yourself still run. Failures caused by the platform or a timeout never count. Auto-deploy resumes after the next successful build or a change to your build settings, or with Resume auto-deploy on the project page.

Each function's page now shows its HTTPS traffic over the last 24 hours: requests, typical response time, the slowest 1% and the server error rate. Until now only queued invocations were counted, so a function answering live traffic looked idle.

Fixed cancelling a running build marking the deployment as failed and emailing you that the build had failed. A cancelled build now stops straight away and shows as cancelled, with no failure email. Builds you did not cancel fail and notify you as before.

Signing in to the deploybase CLI now shows the code from your terminal and asks you to confirm it matches before you approve. Until now the approval page never showed the code, so a link sent by someone else could have approved their terminal on your account. If the codes differ, deny access and nothing is signed in. The same release closes several other findings from a security review.

Your build command now runs as a shell command, so you can chain steps with &&, pipe one command into another and set a variable inline, as in npm run lint && npm run build or NODE_ENV=production pnpm build. Until now anything beyond letters, digits and a few symbols was refused, which forced multi-step builds into a package.json script. The command still runs in your root directory after dependencies install, and a failing step fails the build. Existing build settings keep working unchanged.

You can now set response headers per path on your site: a Content-Security-Policy on /*, CORS on an API folder, a year-long cache on your own fonts. Add a _headers file to your publish directory with a path pattern on one line and the headers indented below it, and the rules apply on production URLs, branch previews and custom domains from your next deploy. A line that cannot be used is skipped and named in your build log, so a typo never fails a deploy. Preview URLs stay hidden from search engines whatever the file says. The format is the one Netlify and Cloudflare Pages use, so an existing file moves over unchanged.

Files your framework names with a content hash, under /_next/static, /_astro, /_app/immutable and /_nuxt, are now served with a one-year immutable cache, so returning visitors load them from their browser instead of asking the CDN again. HTML and every other file keep revalidating on each request, so a new deploy still shows up immediately. Custom domains get this first; sites.deploybase.eu and preview URLs follow in the next few days. Nothing to change in your build.

Your site can answer on several addresses at once: your domain, its www version, and the sites.deploybase.eu address it started with. Search engines treat those as duplicates and split your ranking between them. Pick a primary address on your project's Domains page, and every other address redirects to it, keeping the rest of the URL intact. Your sites.deploybase.eu address redirects too, unless you use it for staging and turn that off. Nothing changes until you choose one.

Fixed unknown URLs returning 200 OK with your 404 page as the body. Search engines read that as a soft 404, which can hold back indexing. Every site on deploybase, including custom domains, now returns a real 404 for a path that does not exist, and still serves your own 404.html as the page when you have one. Single-page apps are unaffected and keep returning 200 on deep routes. Nothing to change on your side.