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.
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.
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.
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.
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.
All data stored and processed in Paris, France — compute, database, and authentication. Sites delivered globally via Bunny.net CDN.