Backend sign-in now signs users' tokens with your app's own key (ES256) and publishes its public key at /auth/v1/.well-known/jwks.json, as hosted Supabase does; tokens and keys from before keep working.
LAN addresses: secretbase lan on puts every app on this computer's network address over HTTPS for the other computers on your network (the main app on 443, the others on 8443, 8444…), with your own certificate or one from this computer's own certificate authority (secretbase lan ca prints it to install); secretbase lan mount serves a program on this computer under a path of an app's address, e.g. map tiles at /globe. On a computer where Tailscale isn't set up, a publish ends as soon as the app is online at its LAN address. Running secretbase lan on again changes only what you give it, e.g. --main keeps your certificate; --domain "" goes back to the IP address only.
Unattended install: the one-line install ending with sh -s -- --admin <user> --accept-terms installs Secretbase with no questions: --admin names who runs it, and --accept-terms accepts the notice, so your first publish goes live.
Updates also work from a download address with a path after the host; only the host is ever shown, and the file that records it can be read only by the administrator.
Uninstalling while apps run now finishes in one go: it stops every app and its Backend parts, and leaves no mounts or network rules behind, so installing again right after works with no restart.
A restart or update in the moment an app's Backend part was starting again no longer leaves it down until the next update: it starts again by itself, and after a restart, update or reinstall an app whose database or sign-in had kept crashing shows healthy as soon as it runs again.
secretbase machines pairing off stops this computer from pairing with other machines (on allows it again); while it is off, secretbase status says so.
Live updates: supabase-js's channels (broadcast, presence and database changes) work at your app's own address. Turn them on per app with secretbase backend <app> realtime on or the Backend tab's Live updates switch; they are off at first and reserve about 256 MB more memory while on.
Functions: your repo's supabase/functions run on Supabase's own Deno runtime, and supabase-js's functions.invoke() works at your app's own address. Turn them on per app with secretbase backend <app> functions on or the Backend tab's Functions switch; they are off at first and reserve about 64 MB more memory while on.
Studio: Supabase's own dashboard for your app's tables, SQL, users and files opens in your browser with secretbase backend <app> studio (from a laptop, add --to <server>). It reserves no memory: it starts when you open it and stops after 30 minutes unused.
Import from Supabase: secretbase backend <app> import (or the Backend tab's Import from Supabase) brings an app on hosted Supabase across in one go: its tables and data, its sign-in users with their passwords, and with its secret key its files and confirm-email setting. It checks the hosted database's certificate against Supabase's own root, so nobody on the way can read the password or the data.
Memory kept free for your own work: when you haven't set it, it is now a quarter of the computer's memory, at most 12 GB, so a small server that only hosts apps fits more of them.
Updates and restarts of a computer whose apps have live updates on stop each app's parts cleanly, its database last, and all apps at once, so with many apps the update still finishes in seconds and your apps stay online.
After an update or a restart of a computer that is full, every app that ran before starts again with all its Backend parts, and Secretbase no longer takes its own stops of a database part for crashes. If the computer then has less memory set aside for apps than they reserve, secretbase status says so, and publishing another app or turning a part on is refused until you take one offline.
Updates wait for your apps' parts to stop for at most 8 seconds. In rare cases (an update right as the computer starts, or a part that won't stop) the old version is stopped by force; the update still completes and your apps keep their addresses.
If an update can't start the part that puts your apps online as its own service, your apps now keep their addresses and stay online meanwhile (before, they could go offline), and the next update brings it back.
Alerts from your own scripts: secretbase alert send emails at most 10 in any hour, and they share your apps' 90 emails a day, so a script stuck in a loop can't use up the emails your real alerts need.
An app that stops right after it starts (it throws at start, say) now says so, with its last log lines, instead of "your app listened on nothing". The release that was live keeps running.
A laptop's secretbase that is older than the server still shows the log lines the server sends with an error it doesn't know yet.
Publishing an app with workers says, in the terminal too (on the server and from a laptop), that its workers don't see the app's /data folder and share data through the app's database.
Right after a server update, a laptop's command says "This server is starting its online address. Try again in a minute." instead of "The server answered 421 Misdirected Request." If its online address can't come up, the command says why (Tailscale couldn't be reached, say) instead.
A pnpm app with no packageManager in package.json installs with the pnpm that wrote its lockfile (pnpm 10 for lockfile 9.0), as on Vercel, not the newest pnpm, whose stricter defaults stopped such installs. With pnpm 10 or newer, install scripts your project doesn't allow (Vite's esbuild, say) are skipped with a warning, instead of stopping the publish.
A server with no browser comes online with only a Tailscale key: secretbase tailscale-key signs it in to Tailscale, no sign-in link to open. A server already signed in is left as it is.
Each person on a shared server reaches only their own apps. Someone in the secretbase group who isn't the user who installed Secretbase sees anyone else's app by name and state only, can't open, change or delete it, and makes App tokens only for their own apps. Server, full-control and co-developer tokens are made only by the user who installed Secretbase: the update revokes the ones others made before (and connected apps they signed in), and lists each one (its name, who made it, what it could do) so you can make again what you want. If it revoked any, secretbase status and the dashboard tell the admin how many until you dismiss it, secretbase tokens revoked lists them, and one alert email carries the list.
secretbase health <app> --to <server> shows an app's CPU and memory from your laptop (a Server token also reads the whole server's with secretbase health --to <server>).
New Docs page, Workers and scheduled jobs: background workers from your Procfile and jobs on a schedule from your secretbase.json, their log lines, and reading them from a laptop.
A single-page app's own links work on a reload or a shared link: list rewrites in your website's secretbase.json, in the same shape as in a vercel.json, such as /** to /index.html.
An app's password is no longer sent with the app's details: secretbase status, the dashboard and the AI tools read it on its own, and only for your own apps.
Anything to do
secretbase update on the server. If other people use the server, each publishes their own apps; the user who installed Secretbase keeps full control.
secretbase undo <app> --to <server> puts an app's previous release back online on that server from your laptop, with the server's token or the app's own token.
An app's public keys are now there when Secretbase builds it, as on Vercel: a Vite or Next.js build bakes in VITE_… or NEXT_PUBLIC_… keys set with --public, and a Dockerfile gets them as build args. Private keys never reach a build. Publish again after changing a public key.
Set Cache-Control and a few safety headers for some paths in your app's secretbase.json, in the same shape as headers in a vercel.json (paths as globs such as /assets/**, with at most one ** and one * in each part), for websites and apps alike.
An app can reach one service on your own network, such as a database on another machine or on this computer: secretbase host-service <app> <address:port>, set by the app's owner on this computer. Off at first.
The one-line install now waits for your answers on Ubuntu 26.04: the risk notice and the online dashboard question no longer pass by on their own.
Publishing an app from another folder while its last publish is still running no longer gets lost: the new publish waits for the running one, then builds and serves the new folder.
A user on the server who isn't one of its admins is now told they don't have access, and how an admin adds them, instead of being told Secretbase isn't running.
Anything to do
secretbase update on the server, and the one-line install with sh -s -- --cli again on a laptop that only has the command.
secretbase alert send --level error "<line>" emails one line to your alert address at once, so your own scripts on the server can alert you through Secretbase's email without a key of their own. It exits with 1 when the email wasn't sent.
When another user on the computer (such as cloud-init's ubuntu) already holds ids in the range Secretbase runs apps with, the install now prints the exact command that moves that user's range to free ids, instead of only refusing. Run it, then the install again.
An app can have several own domains, as on Vercel and Render. secretbase domain <name> adds a name beside the app's others instead of replacing them, and secretbase domain remove takes one off while the others keep answering. On the dashboard, Add another domain adds one and each domain has its own Remove button.
secretbase publish --to sends a big folder in parts and waits while the server unpacks it, so a slow line or Cloudflare in front of the server no longer cuts it off after about 100 seconds, and folders over 100 MB go through. A part that fails is sent again by itself. When something in front of the server still times out, the command says so in plain words and asks you to try again.
secretbase publish <folder> --app <app> now works when the folder the app was last published from has been deleted or moved: an app stays with the user who made it, whatever happens to its old folder. When you can't publish into an app, the command says so in plain words instead of asking you to update.
Only an app's owner, the server's administrator, a Server token or a token for the app can publish it, whoever made the token. Another user on the server who names its folder or its id is told so in plain words and nothing is published; secretbase publish --new makes an app of their own from the folder.
Everyone in the secretbase group on a server can make a Server token with full control: adding someone to the group makes them an admin of this server. The install says so.
Anything to do
secretbase update on the server. On a laptop that only has the command (installed with --cli), run the one-line install from the Download page with sh -s -- --cli again: adding a domain with --to needs this release's command.
Backups keep the links inside an app's own files, so apps installed with pnpm (whose packages are links) restore and start again. A link that points outside the app is still left out of the backup.
A computer that only hosts apps can give them the memory Secretbase used to keep free for your own work. Set "dev_reserve_mb" in the "sandbox" part of /etc/secretbase/config.json (in MB; 0 keeps nothing back), then restart the computer. Left unset, it keeps 12 GB free as before.
An update keeps your "sandbox" settings in that file (the dev reserve and "hosted_memory_mb"). Before, every update wrote the file anew and dropped them.
Domains from a laptop work with an app's own key, and a busy moment no longer shrinks how many apps fit.
What changed
secretbase domain <domain> <app> --to <server> with an app's key now answers truthfully: the domain is saved, or it waits for the owner's OK (with the request's id). It never prints success without a saved domain; an answer it can't read is an error. secretbase domain remove <app> <domain> --to <server> works the same way.
An app has one own-domain address at a time. Adding a new one replaces the old one, and every place you add it (the command, the dashboard, the API and the AI agents' domain tool) now says so before and after: "<old> stops answering; <app> moves to <new>."
The secretbase command and the server now tell each other their versions. A command older than its server prints how to update it, and adding or removing a domain asks an older command to update first.
"Room for about N more apps" and starting new apps now follow the computer's memory as it is now. An update or restart at a busy moment used to keep the count low until the next restart.
Anything to do
secretbase update on the server. On a laptop that only has the command (installed with --cli), run the one-line install from the Download page with sh -s -- --cli again: commands from 1.0.8 and older can't learn about this release by themselves.
Files take a fraction of the disk, aws s3 rm works, you can take a domain off an app, and backup checks of apps with a database pass.
What changed
File storage keeps each app's files in a disk image of their own. A small file now takes about 1 KB of the app's disk instead of 12 KB, and about 2.3 KB on the computer's disk instead of 12 KB. - Existing files move into the image by themselves after the update, one app at a time, smallest first. Each app keeps serving while its files are copied. At the end, uploads wait and the files are unreachable for a few seconds while it switches over: about 8 seconds for an app with 100,000 small files, less for smaller apps. Each app's log shows how long its pause was and how many files it moved. - The old folder is removed only after every file, its size and its details match in the image. If anything doesn't match, the app stays on its folder and the next start tries again. - Backups restore into the image, old backups included. The nightly backup check no longer writes the files out to disk. - Backups keep each file's details at any size (a long Content-Type over 1 KB used to be dropped). - A backup with more than 200,000 files can be restored and checked; the limit now follows what the app's disk can hold.
aws s3 rm and aws s3 sync --delete with aws-cli 2's default client delete files (each delete was refused with SignatureDoesNotMatch).
secretbase domain remove <app> <domain> takes a domain off an app. It removes only the DNS record and route Secretbase made for that domain; the app keeps its other addresses, and you are told first if the domain is its only public address. It asks first (--yes skips the question); if Cloudflare can't be reached it says the removal isn't finished, and running it again finishes it. Also in the API (DELETE /v1/projects/{id}/domains/{name}) and for AI agents (the domain tool).
The nightly backup check of an app with Postgres or Redis on now starts the app's copy with its database address, as the app runs live. Such apps whose code needs DATABASE_URL or REDIS_URL at start were reported as "backup failed" although the backup was good.
Taking an app offline while it was starting up could leave it running. It now stops.
A publish no longer waits 30 seconds when one copy of the app stops while it starts.
A database or file storage that restarts answers again within a second of starting, instead of after about 30 seconds.
Anything to do
Nothing: secretbase update, or the one-line install from the Download page. The install adds e2fsprogs, the tools the disk images need, if the computer doesn't have them.
Faster, roomier file storage, and a new release key. Install this one by hand, once (below); secretbase update works again from the next release.
What changed
File storage, for every app that uses it: - Public files that are read again are answered from memory: about 0.1 ms instead of a few ms. - A missing file answers 404 (it said 400). - Browsers get the Access-Control-Allow-Origin header once (it came twice, which some browsers refuse). - Bulk uploads are 2 to 2.6 times faster: storage and its database use the app's CPUs, not one. - The 50 MB limit per file is gone: a file can be as large as the app's free disk. - Stored files and the app's database now count toward the app's disk, as its other files do.
The disk warning follows the disk: it updates on every check and clears once space is freed.
Each app keeps its live release and the one before it on disk (for Undo), not five.
Releases are signed with a new key. The site's /download/release-key.pub has it.
Anything to do
Once: run the one-line install from the Download page again. Your apps, their data and your settings stay. secretbase update from 1.0.6 or older refuses 1.0.7, because those versions only trust the old key.
Known gap
aws s3 rm (and aws s3 sync --delete) with aws-cli 2's default transfer client deleted nothing. Fixed in 1.0.8.
Clearer status while "Make room" is on. Update with secretbase update.
What changed
secretbase status and the dashboard show an app paused by Make room as paused ("paused by Make room for <app>"), not as offline or needing attention. A paused app sends no alert.
The computer's audit log records an access token's refused request as refused.
Choosing a priority that doesn't exist now says which three there are.
Make room: in an extreme case, you switch one app to come first. Update with secretbase update.
What changed
Each app's Settings has "Priority": Priority, Normal or Background. It matters only when apps compete for the computer: a Priority app gets more of its CPU, a Background app less. Every app starts as Normal.
"Make room for <app>" puts that app first for 1, 6 or 24 hours. First, Background apps give up their extra copies. If the app still doesn't fit, Background apps are paused one at a time until it does. Normal apps are never touched.
While it's on, the app's page shows who switched it on, what it changed and when it ends. Paused apps say "Paused by Make room for <app>".
When you switch it off, or its time ends, everything comes back by itself.
Only you can do this, on the dashboard: no access token can set a priority or make room, so an AI tool can't put its own app first. Every change is recorded in the computer's audit log.
Anything to do
Nothing. Set a priority only if your apps compete for the computer.
Automatic copies: an app stays up through busy moments, at no cost. Update with secretbase update.
What changed
An app can run from 1 to 4 copies by itself. Set it with secretbase resources <app> --copies 1-3, or choose "Automatic" under Copies on the app's page. It runs the fewest copies when quiet, adds a copy within about 2 to 3 minutes when it gets busy, and goes back down one copy at a time after about 10 quiet minutes. Visitors don't see errors while copies come and go.
Status, the app's page and secretbase resources say how many copies run now, for example "2 copies now (automatic 1–3)". The app's activity says when a copy was added or removed, and why.
Your computer comes first: no copy is added when the computer is full or short of memory, and the activity says so once.
A publish keeps the number of copies running, so a release during a busy moment doesn't drop the app to one copy.
Apps that keep files in /data stay at one copy, as before.
Clearer messages: a token that has made its 3 tokens or connected apps now says so, and secretbase activity shows a request for a new web address as such.
Anything to do
Nothing. To use it, set an app's copies to a range, for example secretbase resources <app> --copies 1-3.
When an app's or a co-developer's access token puts an app on a new web address, the owner approves it first (secretbase approvals). Addresses an app already has keep working as before, and a token never adds a new domain to your Cloudflare account.
Revoking an access token also revokes every token it made. One token can make at most 3 tokens or connected apps.
The online dashboard's sign-in counts wrong passwords per network, not per address. Under a flood of wrong passwords, new networks are slowed down, while networks you signed in from in the last 30 days go straight in.
A Dockerfile can't hide a web link in a build variable to fetch files during the build.
Apps' builds no longer share each other's build caches.
An app can send sign-in mail only from the sending domain the owner chose for it. Choose it with secretbase email domain --app <app> <domain>. Apps together send at most 90 emails a day, so alert emails always have room.
Apps no longer receive visitor-made Cloudflare address headers on Tailscale addresses, nor the password-gate cookie of another app on the same address.
Updates, domain changes and the online dashboard's password are recorded in the computer's audit log.
The download page shows how to check that the download matches the signed release.
Anything to do
Nothing. If you run two or more verified sending domains, choose each Backend app's domain once with secretbase email domain --app <app> <domain>.
An app that isn't running yet, for example just after the computer starts or while it can't start, answers its visitors "The app is starting." and never shows the files in its folder. Websites are served as before.
When an access token sets the online dashboard's password, that dashboard can't approve or refuse an AI tool's requests. Answer them on the computer itself, or set the password there with secretbase dashboard on to answer them online again.
Each app's visitor log stops growing at 10 MB a day, so a flood of visitors can't fill the disk.
An approval covers exactly the request that asked for it: two requests never share one approval.
Anything to do
Nothing, unless an access token set your online dashboard's password: then run secretbase dashboard on on the computer once to answer requests online.
The first release of Secretbase. It puts your websites and apps online from your own Linux computer, at a public HTTPS address, each app in its own sandbox. It is free: the addresses come from your own free Tailscale or Cloudflare account.
For a Linux desktop
One install command puts the dashboard app and the secretbase command on Ubuntu, Debian, Fedora or Arch.
Publish a folder, a single page or a .zip with secretbase publish ., or drop it on the dashboard.
Desktop notifications when an app keeps crashing, a backup fails or the disk fills.
For a Linux server
The same install at the keyboard or over SSH, for a computer with no screen that stays on.
Manage it from your laptop: install only the command there, add the server once with a token (secretbase remote add home <address>), and add --to home to publish and manage its apps from anywhere.
An online dashboard, behind a username and password, to manage it from any browser or phone.
Pair several machines: they list each other's apps, publish on each other and keep backup copies of each other's apps.
For both
Publish from a git repository; each push to its branch goes online by itself.
Apps with their own server (Node, Python, Go, a Dockerfile or a Docker Compose file), and websites built with Vite, Astro or Create React App.
Keys for your app's settings and secrets, encrypted and never on the command line.
Your own domain through your own Cloudflare account.
Postgres, Redis and PostGIS for each app, and a release: line in the Procfile for database changes before each release goes live.
Backend: Postgres with pgvector, pg_cron, pg_net and pg_graphql, the Data API with row-level security, sign-in (email and password, magic links, Google and GitHub) and file storage with image resizing, at the app's own address.
Websites get Backend too (secretbase backend my-site on): a site built with Vite, Astro or Create React App, such as what Lovable makes, gets the URL and the publishable key in its build (Backend).
secretbase db connect opens an app's database on your laptop for psql, Prisma, Drizzle or your migration tool.
Nightly encrypted backups, to a USB drive, a storage bucket you own or another machine, checked every night; put an app back here or on a new computer.
Health, alerts by email through your own Resend account, and a bot shield on every app.
Let an AI tool run Secretbase: Claude Code, Claude on the web, desktop or phone, or any tool that speaks MCP, with tokens for one app or the whole server; a token can be made to ask you first before it deletes an app or makes a new one public.
Anything to do
Sign-in mail goes out only from your own domain: set up email with a Resend key made with Full access, run secretbase email domain add <your domain> and add the DNS records it prints (Backend: sign-in).
The first secretbase backend <app> on downloads Backend's images first.
Keep your backups' recovery key somewhere other than the computer: secretbase recovery-key shows it (Backups and restore).