What's new in DeployOS, release by release.
v0.3.10October 29, 2026
Supabase reliability fixes, custom templates can ship their own config files, and the app now tells you about updates itself
Two real Supabase bugs fixed (Realtime could fail to set up, and a size preset didn't apply to the right service). Custom templates can now ship companion config files, use a {domain} placeholder, and generate independent per-service secrets - closing the gaps a customer hit trying to turn a working nginx + PHP 8.5 + Redis WordPress stack into a reusable template. Plus a new backup provider, automated security updates, and DeployOS checking for its own updates instead of waiting for you to ask.
Fixed: Supabase
- –Realtime could fail to initialize correctly on first deploy - a missing database setting meant one of its setup scripts ran invalid SQL instead of assigning the right schema ownership
- –Picking a container size preset for a Supabase deploy silently applied the reduced, scaled-down allocation to every service, including Postgres - instead of giving the gateway (and through it, the preset you actually chose) the full amount
New: custom templates can ship config files, a domain placeholder, and independent secrets
- –A custom template can now include companion files (an nginx.conf, a php.ini, anything a service needs to mount) written into the app folder before it starts, the same mechanism a couple of built-in templates already used internally
- –{domain} is now a template placeholder, alongside the existing {name} and {password} - substituted with the app's real domain at deploy time, so a template's own nginx config can reference it directly instead of being hardcoded per deploy
- –{secret:name} generates an independent secret per name (a separate database password and Redis password, for example) - previously every template could only reuse the one shared {password}
- –Doctor's internal reachability check now sends the same Host header real traffic does - previously it didn't, which could make a perfectly healthy app (one that redirects based on Host, like WordPress does) fail that check for the wrong reason
New: Drime Cloud as an offsite backup destination
- –Alongside S3/B2/Wasabi/R2, offsite backups can now push to Drime Cloud - it has no S3-compatible API, so this bridges through Drime's own backend instead, with the same restic encryption and dedup either way
New: automated OS security updates
- –A per-server toggle installs and configures security-only patches (never a full upgrade, never an automatic reboot) on a nightly schedule - a kernel patch that needs a reboot is flagged, not forced, on a server serving live traffic
New: DeployOS checks for its own updates
- –Previously the only way to find out a new version existed was to open Settings and ask - the app now checks on launch and periodically while open, and lets you know once a real update is available
New: Hermes Agent template
- –Nous Research's self-hosted AI agent is now a one-click template - it deploys as a headless background worker (no domain needed) and needs a provider key (OpenAI or OpenRouter) filled in on the deploy form before it does anything; there's no published container image upstream, so this is the first template built from source on first deploy
Fixed: backups and pre-deploy safety snapshots could pile up on disk forever
- –A database backed up only through the "Backup now" button (or the AI assistant) never had its old local copies cleared, even though the retention setting looked like it applied - only a configured recurring schedule actually did that cleanup. The automatic snapshot taken before any deploy that touches a migration had no cleanup at all, ever
- –Both now clean up old local copies every time they run, not just on a schedule
Fixed: server snapshot backup/restore could look stuck for minutes
- –A first full-server snapshot (or a restore) produces no visible progress at all without this fix - restic goes completely silent until the whole thing finishes when it isn't attached to a terminal, which every connection here is. Both now show live progress instead of a motionless spinner
Fixed: live app previews could show a blank white box
- –The dashboard's live preview of an app's real page - rather than a server-side screenshot - was being blocked by the app's own security policy before it ever reached the target site, and separately couldn't render any JavaScript-driven page (most modern dashboards and WordPress themes) even once that was fixed
Fixed: a couple of things in Settings
- –The "Reverse proxy" row always said Traefik, even if you'd picked Caddy when adding a server - it now reflects what your servers are actually running
- –Some copy there assumed you were on a Mac ("your Mac's Keychain") regardless of your actual OS
- –Added a "Copy for support" button on that same screen
Fixed: a pasted SSH key copied via Notepad could fail with no clear reason
- –Notepad's default encoding can silently add an invisible character to the start of a copied file that breaks key parsing - Test Connection now catches this instantly with a specific message instead of behaving like a slow, unexplained hang
- –Test Connection (and the final step of adding a server) now shows a live log of what it's doing - connecting, handshake, host key, authentication, OS/Docker checks - instead of a spinner with no way to tell what's actually happening
v0.3.9October 23, 2026
Windows: fixed a Credential Manager error that could block saving a server
Saving a server on Windows could fail outright with a cryptic Credential Manager error once its SSH credential was long enough - a longer SSH key, most commonly. Test Connection could also spin for several minutes on a bad or slow connection before telling you anything.
Fixed: saving a server with a long SSH key failed on Windows
- –Windows Credential Manager caps how much a single entry can hold, and a longer SSH private key (RSA keys especially) could exceed it, failing the save with "Attribute 'password encoded as UTF-16' is longer than platform limit of 2560 chars" - credentials are now split and reassembled automatically behind the scenes, the same way long .env files and database passwords already were
Fixed: Test Connection could hang for minutes before failing
- –A bad or slow connection used to retry three times against a timeout sized for a long docker build, so Test Connection could sit spinning for up to ~15 minutes before reporting anything - it now fails within half a minute with a clear message
- –A pasted SSH private key could also fail to authenticate if it picked up Windows-style line endings from copy/paste - keys are now normalized automatically before use
v0.3.8October 22, 2026
AFFiNE joins the template catalog
AFFiNE - the Notion/Miro-style docs-and-whiteboards app - is now a one-click template, with its own bundled Postgres (with the pgvector extension it requires) and Redis, and the one-time setup step it needs run automatically before it ever starts.
New: AFFiNE
- –Deploys with a dedicated Postgres (pgvector-enabled, not plain Postgres - AFFiNE won't start without it) and Redis, plus the one-time database-migration step its own docs require, run automatically as part of the deploy so you never have to shell in and do it by hand
- –First visit takes you straight to account creation - there's no pre-seeded admin login, the same as Wiki.js and a few other templates here
v0.3.7October 18, 2026
Restore a server from an offsite backup — even onto a different one — plus a backup-stats bug, two Doctor blind spots, and a way to actually stop an app
The headline: your offsite backups are now actually restorable, not just takeable — including onto a brand-new server if the original one is gone. Alongside it: a bug where adding the same server twice silently split its stats across two entries is fixed, Doctor now catches a Traefik failure mode it used to miss entirely, and you can finally stop an app without tearing it down.
New: restore from an offsite backup, same server or a different one
- –Database backups and full-server snapshots pushed to S3 (AWS, Backblaze B2, Wasabi, Cloudflare R2, or self-hosted MinIO) can now actually be restored - previously, restoring only worked from a local dump file still sitting on the server that made it, so if that server was ever lost, the copy you'd paid to push offsite was unreachable by anything in the app
- –A full-server snapshot restores onto a brand-new, already-bootstrapped server: every app comes back up, routes republish for whichever proxy that server runs, and the backup/snapshot schedule reinstalls itself automatically - the actual disaster-recovery path this is for
- –Restoring in place (same server) is a Solo feature; restoring onto a different server - and the Pro-only instant app/database migration it's paired with - stays Pro
- –A new Verify action actually restores a backup into a throwaway scratch database and reads it back, rather than just confirming a file exists - the only way to know a backup really works before the day you need it to
- –Backups page now shows a live health signal per database and server ("last backup 1.2h ago" or a clear warning) instead of leaving you to assume a schedule is still running
- –The restic repository password protecting every offsite backup - the one credential that matters most, since losing it makes everything already pushed offsite permanently unreadable - can now be revealed and exported from Settings → Backups instead of only ever existing in the keychain
Fixed: adding the same server twice silently split its stats
- –Nothing stopped you from connecting the same server a second time under a new entry - each one then tracked its own apps and RAM-allocation math independently, so the two disagreed about what was running even though the underlying machine was identical. DeployOS now refuses to add a server at an IP:port it's already connected to, with a clear pointer to the existing entry instead of a second one
Fixed: Doctor could completely miss a dead proxy
- –Traefik getting disconnected from the internal 'edge' network - which breaks routing and certificate issuance for every app on the server, not just one - showed up nowhere in Doctor's checks, because the one check that looked at Traefik only confirmed the container was running, never that it could actually reach anything. Found the hard way, by SSHing in by hand to track it down. Doctor now checks this directly and gives the exact one-line fix when it's wrong
- –Right after SSH hardening switches DeployOS to a non-root admin user, several Doctor checks (container status, edge-network alias, internal reachability, logs) could report false failures - they were running Docker commands without the sudo every other command in the app already uses, and the new user was never actually granted Docker-group access to run them without it. Both sides are fixed: those checks are sudo'd like everything else, and new servers grant the permission directly during bootstrap
New: stop an app without deleting it
- –A Stop action on every app - keeps its config, volumes and images in place so Start brings it back in seconds, unlike Tear down. Useful for a quick bounce, a planned maintenance window, or installing an app and leaving it off until you're ready to go live
- –While stopped, optionally show visitors a placeholder page (Maintenance Mode, Coming Soon, Under Construction, and others) instead of a bare connection error
New: stop the MCP server when DeployOS quits
- –Off by default - an AI assistant (Claude Desktop, Cursor) normally owns and starts the MCP server itself, independent of whether DeployOS's own window is open, which is what lets read-only tools keep working even when it's closed. A new Settings toggle lets you force it to stop the moment DeployOS quits, for anyone who'd rather nothing AI-reachable run unless DeployOS itself is open
Docs
- –The Learn page now has a Frequently Asked Questions section, and new sections covering disaster recovery, stopping/starting an app, Client Hosting Mode and VPN - all previously undocumented there despite each having its own screen
Templates
- –Fixed BookStack and HedgeDoc crash-looping on deploy with no credentials ever generated - both need a real database and were being deployed bare; each now comes with its own bundled database (MariaDB for BookStack, Postgres for HedgeDoc) and the public-URL setting its own docs require behind a reverse proxy
- –Added SQLPad, an in-browser SQL editor and query runner, with its admin login generated the same way every other template's is
v0.3.6October 16, 2026
The terminal stopped disconnecting every 15 seconds, a rebuilt server no longer locks you out, and a real offsite-backup bug is fixed
If the interactive terminal was disconnecting on you constantly, or a server you rebuilt refused to reconnect no matter what you tried, both are fixed. Also: a misconfigured Cloudflare R2 endpoint could make a "successful" backup silently write to the wrong place, with nothing left to clean itself up afterward either - fixed, plus a template removed rather than left broken and a password bug that made it impossible to set one on some accounts.
Fixed: the interactive terminal disconnecting every 15 seconds
- –A recent change added a keepalive to stop an idle terminal from silently dying - but it was treating its own harmless hiccups (a packet that couldn't send instantly, which happens routinely while a session is already streaming output) as proof the whole connection was dead, and reconnecting over it. That meant a brand-new shell - losing your current directory and anything still running - roughly every 15 seconds, including while you were actively typing. It no longer reacts to that; only an actual dropped connection reconnects now, exactly as before this was introduced
Fixed: rebuilding a server could lock you out for good
- –Reinstalling a server's OS (or getting a new one on a recycled IP) changes its SSH host key, which correctly made DeployOS refuse to connect - that check exists to catch a real man-in-the-middle, not just you. The problem: the error told you to remove the server and re-add it, but doing that never actually worked, because the old key was never forgotten. It now is, the moment you remove a server, so re-adding the same one after a rebuild just works
- –For the same situation on a server you haven't removed yet, there's now a one-click "Trust new key" action wherever this comes up (Add Server, re-entering a credential, fetching the deploy key) - no file to find or edit by hand
Fixed: a handful of AI assistant actions could crash the connection
- –Deploying an app, rolling one back, backing up a database, deploying a template, or installing a VPN through your AI assistant could crash the whole MCP connector mid-action instead of completing - a newer part of the app (the "what's currently running" indicator) was never wired up for that separate process. Read-only tools (list apps, fetch logs, Doctor) were never affected
Fixed: offsite backups to Cloudflare R2 and other S3-compatible stores
- –If your endpoint URL already included the bucket name - which is exactly what Cloudflare R2's own dashboard shows you - and the separate Bucket field was also filled in, every backup silently wrote under a nested, wrong prefix instead of to the bucket's root. Nothing failed, so there was no error to see - it just looked like nothing had been backed up when you checked the bucket directly. Fixed at the source, so an already-misconfigured target corrects itself on the next backup with nothing to re-enter
- –The region field on the S3 target form was saved but never actually used - harmless for a provider that ignores region (R2, most others), but would have broken real AWS S3 with a "MissingRegion" error. It's now wired through
- –The S3 target form on the Backups page showed no loading, saving or error feedback at all - a slow save and a failed one looked identical to doing nothing
New: offsite backups now clean themselves up
- –Every offsite push now prunes snapshots past its retention window, scoped so cleaning up one database's or one server's backups can never touch another's - previously every backup or snapshot added to the pile forever, with nothing ever removing an old one
- –Full-server snapshots can now be put on a recurring schedule, the same way per-database backups already could, with the same automatic cleanup
- –DeployOS's own knowledge of your fleet - every server, app, database and template record, plus every credential they reference (SSH keys, your license, this very S3 target's own keys) - can now be backed up offsite too, through the same target. It's the one thing no other backup here protected, since it only ever lived on the machine running DeployOS
Templates
- –Fixed Baserow showing its own "Site not found" page to every real visitor instead of the app - it strictly checks the request against a public URL it needs to be told explicitly, which nothing was doing
- –Rebuilt Outline with Postgres and Redis bundled in, instead of needing them set up separately. It has no username/password login of its own, only OIDC/OAuth, so the deploy screen now asks for your identity provider's details up front and refuses to deploy without them, rather than deploying something nobody could ever log into
- –Removed Discourse from the catalog. Its official image is built around a separate bootstrap process that doesn't accept database or Redis connection details as plain settings the way every other template here does, so every deploy of it was broken from the start - rather than leave a button that doesn't work, it's gone until that's built properly
Interface
- –Native dropdowns (the browser's own menu for a `<select>`) rendered with light-mode colors regardless of the app's own dark theme, most visibly on Windows - fixed
- –Hardened layout in a few delete-confirmation and settings cards where a long label next to a button could overflow a narrow window
Fixed: account page password
- –If you signed up via a magic email link or a redeemed code, your account never had a password - but "Change password" demanded your current one anyway and rejected anything typed there, including nothing. There was no way to ever set one. It now shows "Create password" and asks only for the new one when you don't have one yet
Not releasedOctober 12, 2026targeting v0.3.4
Deploy from a ZIP file, and Windows updates that actually arrive (in progress — not yet available)
Not every buyer has a GitHub repository. This adds a fourth way to get an app into DeployOS: upload a .zip of your project and DeployOS builds it the same way it builds a git-based app. Two Windows-only bugs are fixed alongside it: the AI assistant connection wouldn't start on Windows at all, and the app could never update itself there. All three are built; none are in a released build yet.
The ZIP upload — what it does
- –A new "Upload ZIP" option alongside This Mac / GitHub / URL when adding an app. Pick a .zip, and DeployOS extracts it on the server and runs it through the exact same build pipeline as a git-based app (Railpack auto-detect or your own Dockerfile) - same guardrails scan, same build steps
- –Automatically unwraps a single top-level folder, which is what both GitHub's "Download ZIP" and most zip tools produce by default, so you don't end up with your app nested one level too deep
- –Redeploying without a new upload just rebuilds from what's already there (useful after an env var change); uploading a new .zip replaces the source for the next deploy
What's different from a git-based app
- –No git history means no auto-deploy polling, no branch/PR previews, and no automatic pre-migration database snapshot (the snapshot only knows to trigger off a file diff between commits, which a zip upload doesn't have) - turn on regular database backups separately if that matters to you
- –The "commit" shown for a zip-sourced deploy is just the upload timestamp, not a real git SHA
Fixed: your AI assistant wouldn't connect on Windows
- –If you were on Windows, turning on AI assistant access always ended with "MCP server not working" and an exit code, and no assistant could ever reach DeployOS. The bundled server was building a hidden webview window it had no event loop to drive — macOS tolerates that, Windows refuses, and the process died before it said anything. It now starts with no window at all, which was all it ever needed: everything it reports goes through the app itself, never through a window
- –The AI Access page now shows the actual reason a start-up failed instead of only the exit code. The real cause only ever existed in that message, and it was being thrown away
- –The "connect Claude Code" command it gives you is now quoted the way Windows expects, so the default install path — which contains a space in "Program Files" — arrives as one argument instead of one wrapped in stray quote marks
Fixed: DeployOS could never update itself on Windows
- –Every Windows release published a working installer, but nothing was ever listed for Windows in the update manifest the app checks. The check looked for a Windows entry, found none, and reported a failed update on every machine, on every version — including installs that were already current. macOS was unaffected throughout, which is why this survived every release
- –The cause was in the release configuration rather than the app: builds were set to skip generating the signed update payload, and both publishing scripts treated its absence as a warning and carried on. They now generate it, and a release that has a signing key available but produces no signed payload stops instead of shipping
- –Two follow-on problems are closed with it. The update manifest could pair a Windows installer with the wrong signature, which fails verification at install time; and an entry pointing at an installer that has since been removed is now cleared rather than left behind to fail as a download error. Old installers are also cleaned out of the update folder
What still has to happen before this ships
- –The Windows fixes need a Windows build produced with the updater signing key. That release is also the first one that will publish the Windows update manifest entry, so it is the release that starts auto-updates working — anyone on v0.3.3 has to download that installer once by hand
- –The MCP fix is verified end to end on macOS (the server starts, completes a handshake and serves its tools with no window). It has not yet been run on a real Windows machine; that build is what will confirm it
v0.3.3October 12, 2026
Private GitHub deploys on a hardened server, and a more visible Secret Manager
A deploy on a server where you'd switched off root login (DeployOS's own hardening flow) could fail on a private repo even after the deploy key was added everywhere correctly — fixed. Also: Vault KV v1 support, and a way to see and reuse your Secret Manager's keys instead of flying blind.
Fixed
- –Private GitHub repos could fail to deploy with a generic "could not fetch this repository" error even after the deploy key was correctly added to both GitHub and the server — if you'd also switched DeployOS to connect as a non-root admin user (its own "disable root login" hardening flow). The deploy key only ever lives under root's own SSH config, but the clone/fetch step ran as whichever user DeployOS connects as, so it never found the key on a hardened server. It now always runs with the privilege the deploy key requires, regardless of which user DeployOS is connected as. The same fix applies to the background check that looks for new commits to auto-redeploy
- –The deploy log used to say "Ensured this server's deploy key on GitHub" every time, even when that step had actually failed silently — most commonly because your GitHub token only had collaborator access to the repo, not admin. It now reports what actually happened: added, already present, or the real reason it failed
- –HashiCorp Vault only ever queried the newer KV v2 API shape. An older KV v1 mount returned a 404 on every fetch, which looked identical to a wrong token or path — there was no way to tell them apart. Added a KV version setting (v1/v2) to Settings → Secret provider
Secret Manager
- –Testing a secret provider now lists the actual key names it fetched, instead of just a count — so a wrong path or KV version is obvious instead of looking identical to an empty vault
- –Added an "Insert from Secret Manager" picker to each app's environment variables editor, to pull in one specific key's real value from your global secrets or connected provider (Vault, Infisical, Doppler, 1Password) without having to go find and retype it by hand
Not releasedOctober 9, 2026targeting v0.3.0
Client Hosting Mode, and VPN (in progress — not yet available)
Two features under active development, not yet in a released build. Client Hosting Mode lets you resell space on a server you already own; VPN adds managed OpenVPN to the same server. Both are described below as they stand right now, not as a promise of what's coming.
Client Hosting Mode — what it does
- –Define packages with a real memory, CPU, disk and app-count limit, sign up your own paying clients against them, and bill them however you already collect payment — DeployOS doesn't process a card or take a cut
- –The limit on a package isn't a label: assigning it enforces real Docker memory and CPU caps on the client's app, and the server's remaining capacity is computed the same way on the website and in the app, capped at 90% of a server's real RAM so you can't oversell it from either side
- –Clients get their own login at mydeployos.com — separate from your own account — where they see their services and invoices and can choose WordPress or upload their own files, then tie it to a domain. Their browser never talks to your VPS; what they chose is handed to you to apply from the desktop app, the only thing in DeployOS that ever touches a server
- –A client who stops paying moves from active to a grace period to suspended automatically, based on overdue invoices, with no manual status-flipping; suspending shows their visitors a page you control instead of silently breaking
Client Hosting Mode — what is still outstanding
- –When a client picks WordPress or uploads their own files, that choice reaches you, but the desktop app doesn't act on it yet — you still deploy the app yourself (from an existing template or upload) and apply the pending request to wire up its limits, domain and billing record
- –Billing is manual only right now: you send clients your own payment link or instructions and mark invoices paid yourself. Automatic card charging on your clients' behalf isn't built
VPN — what is working today
- –A new VPN section in the app, which runs a real preflight against a chosen server: OS, architecture, Docker, TUN device, IPv4 forwarding, free disk, sudo, and whether the port is free. It reports which checks are hard blockers and which are only warnings, so you can tell the difference
- –A preview of every change a deployment would make — the container and its capabilities, ports, directories created, forwarding and NAT rules, and the firewall rule — generated without touching the server. The list you approve is the exact list that would run
- –The exact image this deploys has been pinned to a specific, tested version and run end to end by hand: a server starting cleanly, a device certificate issued, a profile exported, and a real tunnel carrying traffic between two machines
How it handles the risky parts
- –Three separate health signals — is the service running, is routing actually forwarding, and has a client really connected. A running container is deliberately not treated as proof that a VPN works, because that's the failure that leaves you quietly unprotected
- –The VPN container runs with no elevated privileges beyond the four it explicitly needs, on its own isolated network, with its own memory and CPU cap so it can't grow unbounded on a server you're also reselling space on. Host networking is not used, and no existing firewall rule is ever removed or flushed
- –Each device gets its own certificate, and revoking one is irreversible by design. Before anything touches host networking you see exactly what will change and have to approve it
- –The VPN's certificate authority, server certificate and revocation list are backed up together. A backup without the certificate authority can't restore revocation state, which would quietly un-revoke devices you'd already locked out
- –Uninstalling removes only what DeployOS created and deliberately leaves the certificate authority in place — deleting it would invalidate every device already issued, so that removal has to be a separate, deliberate act
How it handles your AI assistant
- –Ten purpose-built assistant tools: list options, preflight, preview changes, deploy, health, list devices, create device, revoke device, back up, and uninstall. There's deliberately no general "run this command" tool, and no way to hand an assistant a hostname, an image reference or a shell command
- –Read-only tools are always available; the five that change anything each need their own toggle on and your confirmation. Approving a deployment doesn't authorise anything else later
- –Device private keys and connection profiles never pass through an assistant, never appear in a tool result, and never reach our servers. A profile stays on your VPS until you export it yourself from the app
VPN — what is still outstanding
- –Every test so far has been run by hand against a disposable container, not a real remote VPS reached the way the app actually reaches one, and not a physical device. That's the last gap before this ships, and it's a real one, not a formality
v0.2.1October 9, 2026
Security fixes, and an MCP setup that actually works
A security release. One bug in this list would have let a crafted repository URL run commands on your server, and another handed your database passwords to any AI assistant you connected — so if you're on 0.2.0, update.
Security
- –Fixed a serious bug in stack detection. The repository address and branch were inserted into a command run on your server without escaping, so a crafted value could execute arbitrary commands as your SSH user. Every value is now escaped, and the escaping helper is shared so there is only one implementation of it in the codebase
- –Stopped template passwords reaching AI assistants. Deploying a one-click template generates a real password which was stored alongside the app and handed back verbatim to read-only tools — so any assistant you connected could read your database password. Values inside a container's environment are now stripped before anything is returned, while everything else the assistant needs (domains, ports, health checks, build method) is unchanged
- –Fixed a permissions gap between DeployOS clients on one account: a client could reference another client's uploaded setup file, and it would then be applied to their own service. Uploads are now verified against the service they belong to
- –Updated to the latest Next.js in both the desktop app and the website, resolving a critical advisory. No dependency we ship has a known high or critical vulnerability
- –Rate limiting can no longer be bypassed by forging an IP header, and now survives a server restart. Previously a spoofed header bypassed every limit and a fresh deploy reset them all
Your AI assistant's controls now take effect
- –"Pause AI access" now works — and it no longer switches itself back off. It could fail to reach an assistant that was already running, and that assistant's next write could turn the pause back off by itself. The desktop app is now the only thing that writes those settings
- –Per-tool toggles and "don't ask again" apply immediately, instead of only after you restarted your assistant
Setting up an AI assistant now works on the first try
- –The AI Access page now checks your setup actually works, instead of leaving you to find out by asking your assistant something and seeing nothing happen. It launches the MCP server, confirms it started, and shows the real error if it didn't
- –Correct per-assistant instructions. Claude Code reads .mcp.json, not mcp.json — following the old instructions produced a file nothing read, so your assistant silently never connected. Claude Code, Cursor, Codex and Windsurf now each get the right file and the right format
- –Windows paths are now escaped correctly, so the config you copy on Windows is valid JSON instead of silently failing
Refunds now actually revoke access
- –License checks now re-confirm with our servers at launch, so a refunded or charged-back license drops to free features within one restart. Previously licenses were verified entirely offline, which meant a revoked key kept working forever — and our own refund email promised the opposite. We're sorry it took this long
Corrected information
- –Our docs and pricing pages said Solo was $49 and Pro was $79. The real prices are Solo $79 and Pro $149, and they are now correct across the homepage, pricing pages, comparison pages and the docs that appear in search results. (Lifetime-deal tiers at a lower price still exist as a separate offer — see /ltd.)
- –We claimed 236 one-click templates. The real number is 247. Corrected across the site, our pricing pages, the competitor comparisons and the files AI assistants read
- –Renewals: we advertised that buying again extended your updates automatically. There's no self-serve renewal yet, so the pages now say a person handles it. Your license itself is unaffected — it never expires either way
Under the hood
- –Every release now runs the full test suite, type checks, builds, and a dependency audit before anything is signed or published. Previously nothing was checked before a build shipped
- –Test coverage grew from 70 to 114 tests, including one that runs two real processes against the same settings file to catch the pause-switch bug class of fault
v0.2.0August 12, 2026
MCP safety trio
- –Free-tier MCP gating: write-capable MCP tools require a paid license, checked in the Rust MCP server before every write tool runs — not a UI-only restriction
- –Per-tool write toggles: every write action (deploy, restart, scale, teardown, database writes, cron) is its own off-by-default Settings toggle — 14 read-only tools remain always available and never return secret values (template passwords and env values are stripped before any response)
- –Confirmation prompts: teardown, scale-to-zero, restart on a "critical"-tagged app, and cron removal now require a human "yes" via a cross-process dialog before running, with a 2-minute timeout defaulting to "no" and a per-tool "don't ask again" override
- –Audit log: every write-tool call is now logged locally (tool, target, args, result, duration), filterable in Settings, with CSV export — nothing is transmitted anywhere, and set_env_var logs only the key it changed, never the value
- –Automatic .claudeignore generation on git deploys, written into the checkout DeployOS uses on your server, covering .env*, *.pem, *.key, id_rsa*, .ssh/ and other credential paths
- –Global "Pause AI access" switch that denies every MCP write tool regardless of individual settings (fixed to reach an already-running assistant in 0.2.1)
v0.1.0July 2, 2026
Initial release
- –Push-to-deploy from GitHub to any VPS over SSH, with automatic HTTPS via Traefik or Caddy + Let's Encrypt
- –Managed Postgres, MySQL, MongoDB and Redis databases with a built-in data browser
- –Scheduled backups, including encrypted offsite backup to S3-compatible storage
- –247 one-click app templates (WordPress, Ghost, n8n, Uptime Kuma and more)
- –Server discovery and adoption — import apps and databases you already deployed manually
- –Built-in Doctor: a 9-step diagnostic chain that explains why a deployed app isn't reachable
- –SSH terminal, file manager, cron scheduling and firewall hardening from the desktop app
- –Offline, Ed25519-signed license verification — no phone-home required