Everything we ship, as we ship it: 117 changes since 28 Feb 2026.
43 changes on 17 days
You can now choose who opens a project's production site, at its deploybase address and every custom domain: anyone, only your team, or your team plus anyone with a password you share. Production has its own password, separate from the previews one, and it is free on every plan. Private pages are not cached at the edge, so they load a little slower, and function addresses are not covered yet. The setting is on the project's Domains page.
Fixed custom domains answering plain HTTP requests unencrypted instead of redirecting them to HTTPS. Every custom domain with a certificate now redirects to HTTPS, including domains you added before today.
Rules in a Netlify-style _redirects file now apply on your site: 301, 302 and 308 redirects, 200 rewrites, 404 rules, splats and placeholders, forced rules that override a file that exists, and domain-level rules such as www to your root domain. Lines that cannot be used show up as warnings in your build log instead of failing the deploy. Redeploy an existing deployment to apply its file. The guide is at docs.deploybase.eu/guides/redirects.
Fixed a redirect being cached with the query string of the first visitor who triggered it, so a later visitor could land on a URL carrying someone else's query. Redirects for requests with a query string are no longer cached at the edge.
Builds start sooner and upload your site faster, and direct uploads and promotions finish quicker. Checking a custom domain now answers right away instead of after 10 seconds, and you can check again every 15 seconds.
Dashboard pages load faster, and a request that takes too long now ends with a clear message instead of a page that keeps loading. The API rate limit now counts per endpoint: 300 requests a minute per team, and 1,200 for file uploads.
Your build log now names the package manager and version that installed your dependencies, and whether it came from packageManager in package.json or the platform default. pnpm projects without a packageManager pin now build with pnpm 12.15.0 instead of picking up each new pnpm release.
Server-rendered deployments nothing serves any more are now stopped to free resources, so new deploys no longer fail when old ones pile up. Rolling back to one of them starts it again first, which can take a minute or two; your three newest production deployments stay ready for an instant rollback.
Projects you create from today get an address like name.on.deploybase.dev, on a domain that is separate from the deploybase dashboard. Existing projects keep their sites.deploybase.eu address and custom domains are not affected.
A CI job, a test runner or your AI agent can now get access to one private branch preview for up to an hour: a request header for scripts, or a link a headless browser opens once. Signing everyone out ends that access early. The guide is at docs.deploybase.eu/guides/preview-access-for-agents.
Builds deploy the commit you asked for, and certificate checks give the right advice.
You can now choose who opens a project's branch previews: anyone with the link, only your team, or your team plus anyone with a password you share. Everyone else sees a sign-in page, and with single sign-on your colleagues continue with your company login. It is free on every plan. Existing projects stay public until you change them. Settings, General switches them all at once and sets what new projects start at.
Viewers no longer use a member seat. Free teams can add up to three, and every paid plan has unlimited viewers.
Fixed a custom domain still pointing at another host being told its DNS was correct while its certificate never arrived. The dashboard now names the address your domain resolves to and the record to change, and after a day it checks every 6 hours until you click Retry the certificate.
Connecting a private GitLab repository now starts with one question: deploy every push, or only when you click Deploy. You then get three steps and a link to a GitLab token form that opens filled in. Self-hosted GitLab is recognised and gets a token for just that project. Deploy tokens work too, with their username. If GitLab turns a token down, the message says why and what to tick.
The build log now names the commit it checked out, and a deployment's page links that commit on your Git host. A retry rebuilds the same commit.
You can now connect Claude Code, Cursor, Codex or another AI agent without creating an API key. The agent opens a browser window, you sign in and pick the team it may work in, and it works as you from then on, with at most the Member role. Agents you already connected with a key keep working, and keys remain the way to deploy from CI. Every signed-in agent is listed under Settings, API keys, where you can revoke it in one click.
Hugo sites now build with a current Hugo release, with Dart Sass included. The other build images are up to date too, and from now on they follow new releases. Details are in the Hugo guide at docs.deploybase.eu/guides/hugo.
Fixed a member you removed, or one who left, getting back into your team the next time they signed in. This could happen to the person who created the team and to members who joined through single sign-on. A removed person now lands in another team they belong to, or on a page saying they no longer have access, until someone invites them again. Team API keys keep working after a member leaves, so rotate any key they had.
Viewers on your team, such as a client's staff, still see projects, deployments and domains, but no longer see form submissions, the addresses a form notifies, build logs, function runs or other members' email addresses. Invoices are now visible to admins and owners only. The same limits apply in the API and to AI agents, and a viewer sees a short note where a panel is hidden. If a viewer needs any of this, give them the Member role under Settings, Members.
The projects page and each project's overview now show a screenshot of your site as it is live in production, so you can tell your sites apart without reading their names. A new screenshot is taken a minute or two after each publish, and only your team can see it. A site that never finishes loading keeps its framework icon instead.
Requests to your sites, previews and new custom domains are now answered only by CDN locations in the EU, Iceland and Norway, so your visitors' IP addresses are handled inside the EEA. Visitors elsewhere still reach your site, from the nearest EEA location. Custom domains added before this update stay on worldwide delivery until an admin switches them under Domains, in the Serving region card, where any custom domain can also be set to worldwide. The privacy policy, data processing agreement and subprocessors page now describe this, and the agreement now says server logs are kept 7 days, not 30.
Adding your own records to a domain whose DNS deploybase hosts works for every record type.
Builds that time out or fail in your own build step now count toward build minutes, as successful builds always have. A failure on the platform's side and a cancelled build still never count. In return, a build can now run for 15 minutes on Free and 30 on every paid plan, up from 10. A build that uses 70% of its limit is flagged on its deployment page with its slowest step, so you hear about it before a build fails. A build that does reach the limit names the step that was running and how to speed it up.
HTTP functions can now read the IP address a request came from as context.clientAddress, for rate limiting or blocking abusive callers. The platform sets it, so a caller cannot fake it with headers of their own. It is null on queued calls and scheduled runs.
Signing in is safer. If you were signing in while this update went out, sign in once more.
You can now see what each API key has been doing. API keys shows a key's last action in plain words, such as "Created a deployment of Repro Site, via MCP, 20 min ago", next to its requests over the last 7 days. Select that count for every request it made in the past 90 days, refused ones included. Requests made before this update may show without the project they touched.
Keys made on the Connect your agent screen now expire after 90 days, so an agent you forgot about does not keep access forever. Agent keys you already have get the full 90 days, counted from this update, and keys you create on the API keys page still never expire. Rotating a key is now one click: same name, new secret, and the old one stops working at once. API keys now lists agent keys apart from CI keys and flags any that are about to expire or have not been used in 30 days.
You can now hand deploybase to Claude Code, Cursor, VS Code, Codex or any other AI agent by pasting one prompt: it reads a setup page, connects itself and deploys your project. Creating the API key still takes a person, so an agent without one asks you to sign up and make it, and signing up brings you back to the connect screen. Copy the prompt from the homepage or the agents page, or from Connect your agent when you start a new project, where it already includes a fresh key.
Astro pages that render on demand now work on your custom domains too. Sites already using @deploybase/adapter-astro get this without a redeploy.
You can now deploy Astro 7 sites that render pages on demand on Starter, Pro and Scale: install @deploybase/adapter-astro, add adapter: deploybase() to astro.config.mjs and push. Prerendered pages and assets are still served from the CDN, while on-demand pages, API routes, actions and server islands run on a function in Paris.
Starter, Pro and Scale teams can now serve HTTP functions without applying for the beta, at their plan's memory and concurrency. Requests are not counted while functions are in beta. Teams already in the beta keep their access, whatever their plan.
A symbolic link in your build output is now published only when it points to a file inside the output folder. Other links are left out and listed on the deployment. Sites without such links are not affected.
Two failed deploys now say what went wrong.
Signing in from the command line works again. If it failed for you, run deploybase login once more.
You can now change the email address you sign in with from Profile, without writing to support. If your team signs in through single sign-on, your address is managed there instead.
A new team notification address now has to confirm by email before it gets anything, because that mail carries form submissions and billing. Your owners still get failed payments, security warnings and account notices directly.
You can now run a function on a timetable: add export const schedule = "0 * * * *" to its file and deploy to production. Times are UTC, and how often a schedule may run depends on your plan. A schedule that fails 10 runs in a row pauses itself and emails your team.
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, and a failed build shows the reason and the fix, plus a copy for your AI assistant. 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.
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.
Builds that would publish nothing now stop, and a few pages say what they mean.
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.
40 changes on 19 days
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.
Fixed email confirmation links, and links that no longer work now say why.
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.
Fixed problems with environment variables that could give a build the wrong value or break an import. Nothing to change on your side.
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.
Fixed problems with CLI sign-in and branch previews, and finished rolling out one-year caching for hashed framework assets. Nothing to change on your side.
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.
Fixed builds failing for reasons the dashboard did not explain. Build settings are now checked when you save, and a failed build names what actually went wrong. Nothing to change on your side.
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.
Connect Keycloak, Authentik or another spec-compliant OpenID Connect provider under Settings → Single sign-on. Paste the issuer address and deploybase reads its discovery document and fills in the endpoints, so you only add a client id and secret. Connecting a provider adds a way in, it never takes one away: email and password keep working for everyone on your team, so a setting typed wrong locks nobody out. Included on every plan, free included.
Fixed builds failing with "Upload failed" and a hint to retry when the real problem was the output directory setting. The failure now names the directory that was missing and the one your build actually wrote to, so you can correct the setting instead of retrying a build that could never succeed. Fixed other build failures showing only the generic "Build failed. Check the logs above" line as well; the specific reason is shown again.
Build succeeded emails are now off for everyone, including teams that had them on; turn them back on under Settings → Notifications if you want them. A build that fails after a push now emails your team, at most once per project every six hours while it stays broken. Until now only builds started from the dashboard sent a failure email, so a push that broke your site went unreported until you looked. A deploy you start yourself is still mailed to you directly, every time.
Fixed custom domains keeping the previous build when you promoted an older deployment from the dashboard or the MCP tool. Your deploybase URL switched right away, but the domain you actually share stayed on the old build until your next push. Every promotion now moves your custom domains with it, and a rollback puts them back at the same time. Nothing to change on your side.
You can now belong to more than one team and switch between them from the team menu in the top bar. Everything you see, create or deploy belongs to the team shown there, and the choice sticks across tabs and your next login. Projects, domains and billing stay with the team they were created in; nothing moves when you switch. Accept an invitation from another team and it appears in the menu next to your own.
Fixed folder and CLI uploads failing at the very last step. Your files reached storage intact, but the check that confirms they landed was broken, so uploads were marked failed seconds after they had already finished. Every attempt since 13 September hit this, whether you dragged a folder onto the dashboard or ran the CLI. If you tried and gave up, it works now: upload again, with nothing to change on your side. Sorry for the failed attempts and the time they cost.
Your team now has a name and a URL, so invitations say "join Acme on deploybase" instead of quoting an ID. Both were picked from your account; team owners can change them under Settings → General. If you rename the URL, the old one keeps working until another team claims it, and for 30 days only you can take it back.
When your build has to wait, the dashboard now shows how many are ahead, roughly when it will start, and each step forward as it happens. Pro and Scale builds go to the front of the line, as those plans promise. Fixed builds failing with a capacity error on 14 September when every slot was busy; they now wait their turn instead.
You can now publish a site by dragging its folder onto the dashboard. No repository, no terminal, no build step. It is the same upload the CLI does, with the same limits, and it produces an ordinary deployment you can roll back, share or point a domain at. Choose Upload a folder when you create a project.
You can now run server code next to your static site. Put a JavaScript or TypeScript file in a functions/ directory and push to your production branch: it is served at its own HTTPS hostname, and the same file can be queued through the API and polled for the result. The handler takes a standard Request and returns a Response, the shape Netlify, Cloudflare and Deno use. Functions scale to zero, so the first call after a quiet spell takes 2 to 5 seconds. This is a closed beta: a team owner or admin applies from the Billing page, where the invitation appears once your team is at least three days old. Newer team? Email support@deploybase.eu. Functions are free during the beta, with 30 days notice by email before that changes. Start at docs.deploybase.eu/functions.
The Root directory field now lists the folders in your repository so you can click the one you want instead of typing the path. It follows the branch you selected. Repositories connected by Git URL keep the text box, and so does a repository too large for us to list.
Every site on deploybase, including custom domains, now accepts only TLS 1.2 and TLS 1.3. Connections using the older TLS 1.0 and 1.1 are refused. Those versions were deprecated in 2021, and any site still accepting them is capped at a B on SSL Labs. Nothing changes for visitors on any browser released in the last decade, and there is nothing for you to configure: the change is already live on every domain we serve, and new custom domains get it from the moment they are created. If an old script or embedded device stops reaching your site, TLS is the first thing to check.
You can now connect a Codeberg or Forgejo repository without handing deploybase a token to keep. Choose No stored token when you add credentials, and deploybase signs a short-lived token for each deploy that your own instance verifies, so nothing long-lived sits on our side. It needs Forgejo 16 or newer: deploybase checks what your instance supports and only offers the option where it works, so Gitea and older Forgejo versions carry on with access tokens. Setup takes a few minutes under Authorized Integrations in your Forgejo settings, and deploybase gives you the exact rules to paste, scoped to that one repository and your account. Existing projects are untouched and keep their stored tokens until you switch.
You can now publish a finished site without a Git repository and without a build on our side. Run deploybase deploy ./dist, or point it at a zip, and the CLI uploads your files and puts the deployment live, with the URL printed when it is done. It works with any static site generator, with a site exported from a builder, and from a CI job that already produced the output: set DEPLOYBASE_API_KEY and add one line. Uploads go to production by default; pass --preview with a name to get a preview address instead. Uploaded deployments are ordinary deployments, so rollback, share links and custom domains work the same way. Limits are 25 MiB per file, 20,000 files, and 250 MiB per upload on the free plan or 1 GiB on paid plans. Uploads use no build minutes. This is the answer to the most common question we got after our last launch post: no, you do not have to use Git. Install the CLI with go install codeberg.org/deploybase/deploybase-cli@latest and see the guide at docs.deploybase.eu/guides/deploy-prebuilt.
You can now change the label in your branch preview addresses. Every preview of a project lives at {branch}-{label}.previews.deploybase.eu, and until now that label was fixed to the name your project had when you created it. Open Project, then Settings, then Preview hostname, pick a new label, and every open preview moves to its new address right away, with nothing to rebuild. The old addresses stop working, so update bookmarks, CI scripts and any callback URLs that point at a preview. The freed label stays reserved for your team for 30 days, so you can switch back. Nothing changes until you edit the field. Preview labels are also unique across deploybase now, so two teams can no longer end up sharing one preview address.
Fixed the billing page sending you to a page that did not exist when you hit your preview or share link limit. The Manage previews and Revoke a link actions now open your projects, where a preview is deleted from the project page and a share link is revoked from its deployment. If you have several projects, the new deployments page lists every open preview in one place and lets you retire them from there.
You can now see every deployment across your projects on one page, at app.deploybase.eu/deployments. Deployments are grouped by project, each header shows what is live right now and how many branch previews are open, and you can retire a preview straight from the list instead of opening each project in turn. Search by branch, commit or project, filter by status or type, or switch to a plain newest-first timeline. Deleting a preview only retires its URL: the deployment stays in your history and production is never affected. The page shows your 100 most recent deployments; pick a project to look further back within it.
Anyone can now report a site hosted on deploybase at deploybase.eu/report-abuse, with or without an account. Give us the URL, what is wrong, and an email address; you get a confirmation straight away and we review every report within two business days. This is the notice-and-action channel the EU Digital Services Act asks of hosting providers, and it is also how you reach us if someone is impersonating your brand on our platform. Our acceptable use policy now spells out what we do not allow, from phishing pages and malware to doorway pages built to game search rankings, and how we respond: a warning where the risk allows, then suspension, then removal. Existing sites are unaffected unless they break those rules. If you think we got a decision wrong, write to abuse@deploybase.eu and we will look again.
You can now follow what changes in deploybase without leaving the dashboard. A bell in the top bar lists the latest changelog entries and any notices from us, with a dot until you have opened it. Each entry links to the full text on this page, and a notice that needs your acknowledgement, such as updated terms, asks for it right there. You start with nothing marked unread, so joining a team does not greet you with months of history. Everything in the bell is also on this page and in its RSS feed, so nothing moves out of reach.
Fixed sign-in failing with a server error for a new organisation whose name matched an existing team's. The first visit tried to create the team under a name that was already taken, failed, and every page after that showed the same error, so you could not get past it by trying again. New teams now get a slightly longer address when the short one is taken, and teams already set up are not affected.
Fixed projects created since 1 September deploying without their sites.deploybase.eu address: the build finished, but the dashboard showed no URL and the site returned a 404. New branch previews and share links had the same problem, and single-page apps deployed in that window did not get their deep-link fallback. Existing sites were not affected. The cause was on our side: the deep-link fix from 1 September configured CDN rules in a way our provider accepts for updates but rejects for new sites. If a project you created this week has no public URL, deploy it once more and the address appears within a minute.
Reloading or sharing a URL like yoursite.eu/dashboard/settings on a single-page app returned a 404 instead of your app. The first page load worked, so it only showed up on a refresh or a pasted link, and it affected production URLs, branch previews and custom domains alike. Custom 404.html pages had the same problem. The cause was on our side: the CDN rule that falls back to your app shell was configured in a way that never actually fired. If your build output has a 200.html, a _redirects catch-all, or a 404.html, redeploy once after this release and deep links will work.
deploybase.eu/open now shows the same numbers we look at every day: deployments, build minutes, success rate, bandwidth, form submissions and more, straight from the production database that serves the product. Nothing on the page is hand-edited, and we will not quietly drop a metric in a bad month. Every figure is served by a public API endpoint, so you can verify our claims yourself instead of taking our word for them. Only aggregate platform totals appear, never anything about your team or your sites. The page also explains why we publish this; the short version is that we think the internet gets better when companies show their work.
Eight fixes this round: five from the onboarding feedback you sent, three from our own audits. Thank you for the sharp reports.
17 changes on 10 days
You can now add any email address as a recipient of a form's submissions, no deploybase account needed. Add your client's address in the form's settings and they get one confirmation email; nothing is sent until they click it. After that, every submission arrives in their inbox with the full content, so they never have to log in anywhere. Existing forms are unchanged until you add a recipient, and adding or removing one needs the admin role. Built for agencies: you run the site, your client answers the enquiries.
Creating an account is now protected against automated signups, and the check runs entirely on our own infrastructure. There's no puzzle to solve and no images to click — your browser quietly does a small piece of maths while you fill in the form. Nothing about you is sent to Google, Cloudflare, or any other bot-detection service, because there isn't one in the path. Signing in and signing up were already free of third-party requests; this keeps them that way. One thing to know: signing up with email and password now needs JavaScript enabled. Signing up with GitHub works either way.
When you point a domain at our nameservers, we now confirm the change by asking your domain's registry directly instead of waiting for public DNS caches to catch up. Delegation is typically confirmed within a minute of your registrar applying the change, where it could previously take hours. A new Check now button runs the same check on demand and, if your domain still points elsewhere, shows the exact nameservers we found so you know what's left to change. We also warn you when DNSSEC is enabled at your registrar, which silently blocks delegation until you turn it off there. Applies to domains using 'We host your DNS'; domains already connected are unaffected.
Four fixes for problems you reported this week: three in custom domains, one in the docs. All four were reported within a day of someone hitting them. Thank you for the sharp reports.
You can now let deploybase host your domain's DNS, in beta. Choose 'We host your DNS' when adding a custom domain and delegate your nameservers to us once. The apex domain and www are wired up automatically, SSL is issued without any verification records, and your domain stays registered where it is. This is the way around the classic apex problem: if your DNS provider doesn't support ALIAS records, the root domain simply couldn't point at us before. Domains already connected keep their current setup. This option appeared in our docs earlier but was never switched on in production. It's enabled now.
Every subprocessor we use is now listed publicly at deploybase.eu/subprocessors: what each one does, where it runs, and the legal basis for any data transfer. Each vendor has a stable deep link you can cite in your own privacy policy or DPA review. Most platforms bury this in a PDF or behind a sales call. We think you should be able to check it in ten seconds, no signup, no email gate.
Deep links into your single-page app now serve your app instead of a 404 — reload /dashboard/settings on a SvelteKit or React SPA and it just works. Ship a 200.html in your build output, or a _redirects file with the catch-all /* /index.html 200, and every unknown path falls back to your app on production URLs, branch previews, and custom domains alike. Custom 404.html pages now also work on custom domains. If a site has both, the SPA fallback wins, matching what you'd expect coming from Netlify. Existing projects pick this up on their next deploy or promotion — nothing to configure. One honest note: custom 404 pages are currently served with a 200 status code. Reported by one of our first users.
Fixed search on docs.deploybase.eu hanging on 'Searching…' forever — the search index was silently missing from our docs builds, and every release now verifies it exists before shipping. The docs also got a redesign along the way: a landing page that shows the path from git push to live, clearer navigation with visibly clickable links throughout, and full keyboard and screen-reader support meeting WCAG 2.1 AA. Thanks to the user who reported the broken search.
Clicking a project's URL in the projects list now opens your live site, and clicking the repository name opens the repository — each in a new tab, marked with a small external-link icon. Clicking anywhere else on the row still opens the project itself. Projects with a failed or in-progress build now sort to the top of the list, so anything that needs your attention is the first thing you see. The framework badge is gone (the icon already told you), and the docs are now one click away from the top navigation, wherever you are in the app. Suggested by one of our first users.
Reliability fixes across billing — mostly felt when a payment didn't go through cleanly the first time.
You can now use Bun as your project's package manager. If your repository has a bun.lock or bun.lockb lockfile, builds detect it and install dependencies with bun install, frozen to your lockfile so versions resolve exactly as they do on your machine. You can also pick Bun explicitly in your project's build settings. As with every package manager, dependency lifecycle scripts stay disabled during install, so a compromised package can't run code in your build. Existing projects are unaffected, and if you set a custom build command as a Bun workaround, it keeps working — you can simply remove it now.
You can now erase your account and everything in it from Settings → Account, covering your right to erasure under GDPR Article 17 without emailing support. Requesting deletion starts a 14-day grace period: nothing is removed during it, your sites stay online, and you can cancel with one click. Once the period ends, erasure runs automatically and removes your projects, deployments, stored files, custom domains, form submissions, team data, and your sign-in identity. Invoices stay with Creem, our payment provider, for the 7 years tax law requires, and we keep one anonymous record that the deletion happened. Download your data first if you want a copy.
You can now upgrade, downgrade, or switch between monthly and annual billing directly from the billing page. Changes apply immediately: the unused portion of your current plan is prorated against the new price and settled on your existing payment method, with no new checkout. Previously, changing plans as an existing subscriber could start a second checkout and, in the worst case, charge you twice. That path is now closed: if you already have a subscription, starting a checkout is refused and the billing page routes you through the plan change instead. Moving to the Free plan works through cancellation, so you keep your paid features until the end of the period you've paid for.
Settings → Account now shows every record that identifies you as a person — your profile, the teams you belong to, invitations sent to your address, and feedback you've sent us — and lets you download the lot as JSON. That covers your right of access and data portability under GDPR Articles 15 and 20, without emailing support and waiting. Work owned by a team, like projects, deployments and forms, isn't part of it: those stay with the team when you leave. Downloading changes nothing, and support@deploybase.eu still handles anything the page doesn't cover.
If your account has a passkey, deploybase now asks for it as soon as you've entered your email — one tap with Face ID, Touch ID, or your security key instead of typing a password. Password and two-factor sign-in keep working exactly as before. You can add a passkey any time in your account's security settings.
Smaller updates from the past few weeks across billing, forms, builds, and domains.
You can now create your deploybase account and sign in with GitHub — no password to invent, and you're ready to connect a repository the moment you land in the dashboard. Existing email accounts keep working unchanged.
2 changes on 2 days
Builds now detect your package manager from your lockfile — pnpm, npm, Yarn, or Bun — and install dependencies with it, so lockfiles resolve exactly as they do on your machine. Existing projects keep their configured install command; you can override the detected choice in your project's build settings.
You can now point any HTML form at a deploybase endpoint and collect submissions. They're stored in the EU, filtered for spam without CAPTCHAs, and emailed to your team.
2 changes on 2 days
You can now deploy and manage your sites without leaving the terminal. Log in, trigger deploys, tail build logs, check status, and open your site — all from the CLI.
You can now collaborate on deploybase with your team. Invite members via email, assign roles (owner, admin, member), and control who can deploy, manage settings, or handle billing.
12 changes on 7 days
Browse getting-started guides, framework references, and API docs at docs.deploybase.eu.
Correct VAT is now applied automatically for every EU country, with proper invoices for every transaction. No manual tax configuration needed.
Every plan now has generous hard limits. No overages, no variable charges — your bill is the same every month.
You can now manage environment variables per project. Variables are encrypted at rest and injected at build time for all supported frameworks.
Push to GitHub, GitLab, or Codeberg and your site deploys automatically. Each provider's webhook format is supported natively with signature verification.
A step-by-step project creation flow that detects your framework, configures build settings, and sets up Git webhooks — all in one smooth experience.
Four plans with transparent EUR pricing. No per-seat charges — bring your whole team on Pro and Scale.
You can now manage deploybase projects directly from Claude, Cursor, or any MCP-compatible AI assistant. Check project status, trigger deployments, manage domains — all from your AI workflow.
You can now sign up and start deploying. Compare features, pick a plan, and get your first site live in under two minutes.
Build output now shows distinct stages (clone, install, build, deploy) with error classification, so you can pinpoint failures faster.
Our privacy policy and terms of service are published. GDPR-compliant data handling, transparent about what we collect and why.
Get notified by email when your builds succeed or fail. Manage notification preferences per type from your account settings.
1 change on 1 day
All data stored and processed in Paris, France — compute, database, and authentication. Sites delivered globally via Bunny.net CDN.