2 security incidents: Zeabur shuts servers by December 31
Zeabur is winding down after 2 security incidents in H2 2026. If you run apps there, your hosting now has a hard shutdown date.
Kill posts8 min read
Tim Neunzig
2 security incidents were enough. Zeabur announced on October 17, 2026 that it is winding down after about 3.5 years.
You do not have a platform problem now. You have a calendar problem. Shared clusters pause from December 1, 2026. All dedicated servers and shared clusters shut down by December 31, 2026.
The pitch was automatic builds, deploys, servers, domains, logs, databases and AI helpers. The reality is simpler. Your apps need to be somewhere else before the lights go out.
What happened
Zeabur is a PaaS for automatic builds and deployments. It runs services on shared clusters or dedicated servers. It supports managed databases, custom domains, DNS, logs, resource limits, an email service, self-managed servers and AI deployment features such as zbplan and Zeabur Agent.
That is the product layer. The company layer is now a shutdown notice.
Zeabur said on October 17, 2026 that it is winding down. The company described the run as 'about 3.5 years'. New dedicated-server and domain purchases stopped immediately. Dedicated-server renewals are disabled. Shared clusters are paused from December 1, 2026. All dedicated servers and shared clusters shut down by December 31, 2026.
The cause was not slow growth in the text you have to care about. It followed a breach.
The shutdown post says an external attacker reached internal systems and some customer services on October 14, 2026. The kill sheet identifies this as the second security incident in H2 2026. That is the number in the headline. 2 security incidents. One platform. Your production apps in the middle.
The final housekeeping is still missing. The data-deletion date is unknown. The final export deadline is unknown. The support closing date is unknown. That is not a detail. That is your migration risk.
Zeabur also announced limits on the way out. Purchases for dedicated servers and domains stopped. Renewals for dedicated servers are disabled. Shared clusters pause before the final shutdown. If you are still treating Zeabur as normal hosting after December 1, 2026, you are pretending.
Pricing was still public. Free was $0 per month. Dev was $5 per month. Pro was $19 per month. Team was $79 per month including 3 seats, with extra seats at $24 per month. Enterprise pricing was custom and not public. For a 10-person team on Team, the math is not subtle: ($79 Team plan including 3 seats + 7 extra seats at $24) x 36 months = $8,892.
That is the rent number. It is not the real problem. The real problem is that rent does not buy continuity when the landlord has already posted the closing date.
What it actually did for you
You used Zeabur because it removed boring work. That part was real.
You pushed code from GitHub and expected automatic builds. You deployed services without copying files by hand. You ran long-lived containers for n8n, OpenClaw and AI apps. You attached public URLs. You stored state in managed databases. You used backups or exports because app state matters. You set environment variables. You set resource limits. You used logs when deploys failed. You pointed domains at services. You triggered deploys through API keys and webhooks.
That is the daily product.
The daily product is not high-availability deployment for every small side app. It is not Wonder Mesh device connectivity if your team never wired it into anything. It is not gateway IP allow and block rules if you never used them. It is not the email service if mail already lives somewhere else. It is not custom service icons. It is not domain purchasing through Zeabur if your registrar can hold DNS. It is not Zeabur Agent if your real workflow is still GitHub, Docker, Postgres and logs.
This is where SaaS rent gets dirty. You pay for the whole surface area. You depend on the boring core. When the vendor dies for customers, the shiny parts do not matter. The boring core must be rebuilt first.
So do not rebuild Zeabur. That is how teams waste the last quiet weeks before a shutdown. Rebuild the operating slice you actually use: repos, builds, containers, databases, secrets, logs, backups and DNS cutover.
Everything else is decoration. Decoration does not keep n8n running.
The math
| Option | Tier | Price per user per month | Team size | 36 months | Total |
|---|---|---|---|---|---|
| Zeabur rent | Team | $79/month includes 3 seats, +$24/month per extra seat | 10 | 36 | $8,892 |
| Owned build | Pro replacement build | $0 per-user PaaS rent, server costs unknown | 10 | 36 | $2,500 to $8,000 |
You keep $892 over three years at the top of the build range, before server costs, and you keep the code, the runbook and the deployment stack. Payback is 33 months against the $8,000 build ceiling.
That is the conservative version. The lower build number is $2,500. The server bill is unknown because your current CPU, memory, storage and traffic are not in the kill sheet. Do not invent it. Measure it.
The important part is not that owned hosting is magic. It is not. The important part is that per-seat PaaS rent stops being the gatekeeper for your own deploys. A developer who needs to push a service should not become another recurring seat on a platform with an end date.
What you would build instead
- App deploy runner: connect GitHub repos to container builds and redeploy only the selected services. Use Docker containers for each app.
- Service catalog: define the current services, such as n8n, OpenClaw and AI apps, with ports, domains, environment variables and resource limits.
- Database layer: run Postgres and restore Zeabur database exports or app-level backups. Test restores before DNS moves.
- Logs and backup jobs: keep runtime logs and scheduled backups on the client-owned server or a storage target you control.
- Domain cutover runbook: move domains and DNS records away from Zeabur before December 31, 2026. Final export and deletion dates are still unknown.
- Access and triggers: recreate API keys, webhooks, GitHub deploy hooks and log forwarding where the current services use them.
The stack is plain. Client-owned Linux server. Coolify or CapRover as the self-hosted PaaS. Docker for the workloads. Postgres for application databases. GitHub for source repositories. DNS at your registrar or existing DNS provider. Start with one client-owned server. Add more only if the current Zeabur services actually need it. The server contract stays between you and the infrastructure provider.
Open-source building blocks are already sitting there. Coolify is Apache-2.0, has 63,262 stars in the kill sheet and had a last commit on October 20, 2026. Its role is the primary self-hosted PaaS option with one-click services including n8n. CapRover is Apache-2.0, has 15,186 stars and had a last commit on October 19, 2026. Its role is the mature self-hosted PaaS option with a one-click app catalog. Dokploy is Apache-2.0 with additional terms, has 37,886 stars and had a last commit on October 16, 2026. Its role is an alternative self-hosted PaaS built on Docker and Traefik.
Data migration is not optional. Export GitHub repositories, database backups, environment variables, domain and DNS settings, and service resource settings. Restore databases to Postgres. Recreate services in the self-hosted PaaS. Test internal URLs first. Test public domains next. Cut DNS over before the shutdown. Keep the old setup until the new one has served real traffic and backups have restored successfully.
You lose things. You lose Zeabur shared clusters and dedicated-server lifecycle management. You lose Zeabur AI build planning and Zeabur Agent. You lose domain purchase and email service through Zeabur. You lose Pro priority support and vendor support in general. You lose high-availability deployment features, Wonder Mesh connectivity, gateway IP allow and block rules, custom service icons and any Claude Code or Codex migration skills announced by Zeabur. If those were central to your operation, keep them in the migration scope. If they were not, leave them dead.
Who should do this
Do this if you are an indie developer with live n8n, OpenClaw or AI services on Zeabur and you need them running after December 31, 2026. You do not need a perfect internal platform. You need deploys, databases, domains, logs and backups on infrastructure you control.
Do this if you are a startup or small dev team with around 10 people on Team pricing. Your 3-year Zeabur rent is $8,892 before the shutdown makes the rent theoretical. A $2,500 to $8,000 owned build fits when the scope stays narrow and the current services are known.
Do this if you have customer-facing apps with custom domains. DNS cutover is not a nice-to-have. It is the difference between migration and outage.
Keep renting elsewhere if you need managed high availability, vendor support, multi-region operations or security controls you do not have the staff to run. Also keep renting if your current Zeabur footprint is temporary and can be deleted instead of migrated. Deleting a dead experiment is cheaper than rebuilding it.
The SaaSKiller Take If your apps run on Zeabur, your hosting now has an end date. A 10-person team on Team is looking at $8,892 over three years, but the bigger problem is that the platform disappears by December 31, 2026. Move the current services to a server you control and rebuild only the deploys, databases, domains, logs and backups you actually use.
Sources
AI-generated