Zeabur, a cloud deployment platform used to host websites, databases and tools such as n8n, has announced that it will gradually stop operating, with all services ending by 31 December 2026. For teams on the platform the priority is to back up and move before their own services stop. For everyone else it is a reminder that any hosting provider can change course, and that an exit plan is easier to write before you need it.
What was announced
According to reports by INSIDE and Mega News, founder Yuanlin Lin (林沅霖) emailed users on 17 October 2026. The reported points are:
- Immediately: no new dedicated server or domain purchases.
- From 1 December: dedicated servers stop renewing and shut down during December on their own expiry dates. Shared clusters are paused the same day; users can restore services manually to take backups.
- 31 December: all services end. Zeabur warned that this does not mean every service runs until that day.
- Still to be announced: the data deletion date, the final export deadline and the date customer support ends.
- Domains and money: domains bought through Zeabur can be transferred out by users themselves. Account balance refunds and claims for losses from the security incidents are handled separately through Zeabur Support.
The reports say the team plans to publish migration guides in Markdown, including material for AI coding assistants. INSIDE noted that when it checked, the shutdown notice had not yet appeared on Zeabur's blog or status page; the details above come from the user email as reported.
Why Zeabur says it is closing
In the email, as reported, the founder said the team reviewed system security, operating workload and the investment needed to continue, and decided to wind down. He also said AI had increased demand for deployment but lowered the barrier to deploying, and that the platform's growth had begun to stall.
The decision followed two security incidents. Zeabur's own August incident report describes an attacker who exploited a vulnerability in a user's public service, moved from the shared cluster into internal systems and read project environment variables, including third-party API keys and database passwords. Zeabur then disabled its legacy API keys and later discontinued its AI Hub service. The October incident update on its status page says some Google Cloud dedicated servers were also accessed and that the attacker had read access to the platform database, exposing service environment variables, account information, API tokens and zSend keys.
What affected teams should do now
- Find your real deadline. Check each dedicated server's expiry date. For shared clusters, plan around 1 December, not 31 December.
- Rotate secrets. Zeabur's status page advises rotating every secret stored in environment variables and regenerating Zeabur API tokens. Do this regardless of the move, and do not copy old secrets to the new host.
- Back up data first. Export databases and persistent storage and test that a backup restores elsewhere before anything is switched off.
- Export configuration. Zeabur's documentation describes exporting a project's YAML configuration; keep it as a record of services, ports and settings.
- Move domains and DNS. Transfer any domain registered through Zeabur, lower DNS TTLs before the switch, and update records once the new host is ready.
- Request refunds or claims early through Zeabur Support, and keep copies of invoices and correspondence.
Lessons for anyone using a hosting platform
Platforms like Zeabur save real time: push code and it builds, deploys and connects a database. The trade-off is that more of your setup lives inside one provider. These habits reduce the cost of leaving, whichever provider you use.
Know where your lock-in is
List what only works on the current platform: proprietary build settings, managed databases without a standard export, built-in email or queue services, and domains bought through the provider. Each one is a step in a future migration.
Keep data portable and backups off-platform
Schedule regular database dumps and file backups to storage you control outside the provider, and test restoring them. A backup that only exists inside the platform you are leaving does not help much.
Describe infrastructure in code and containers
Dockerfiles, configuration files and infrastructure-as-code let another provider rebuild the same setup. A CI/CD pipeline in your own repository, rather than only in a platform dashboard, means deploys can be pointed at a new target. A staging environment on the new host lets you test before switching traffic.
Treat secrets as temporary
Store secrets in a manager you control, give each key the narrowest permissions it needs, and know how to rotate all of them quickly. Both Zeabur incidents involved credentials stored in environment variables. Our zero trust and MFA guides cover related access controls.
Be ready for a second provider
You do not need to run everything twice. Keep DNS with a registrar you control, know which alternative host you would use, and record the steps to move. A CDN in front of your site can make switching origin servers less disruptive.
Watch from outside
External website monitoring tells you when a site or key flow fails, whichever host it is on. Subscribe to your providers' status pages and make sure notices reach an inbox someone reads.
An exit-plan checklist for SMEs
- A list of every service, database, domain and secret, and which provider holds each.
- Backups stored outside the hosting provider, with a restore tested in the last quarter.
- Build and deploy configuration kept in your own code repository.
- Domain registration and DNS under an account the business owns.
- A named alternative provider and a written migration runbook.
- A way to rotate all secrets within a day.
- Contract terms on notice periods, data export and refunds, checked with an adviser where needed.
- A support SLA that says who handles an incident or migration.
Illustrative example: a small online shop runs its website, database and a booking tool on one platform. With weekly database exports to its own cloud storage, its code and Dockerfile in a Git repository and its domain at a separate registrar, a forced move is mostly redeploying, restoring and repointing DNS. Without those, the same move starts with working out what exists and where.
technine.io helps businesses plan maintenance, monitoring and migrations through managed support and SLA services, and reviews credentials and access through cybersecurity and compliance work.
Frequently asked questions
When do Zeabur services actually stop?
As reported, shared clusters pause on 1 December 2026 and dedicated servers shut down on their own expiry dates during December, with everything ending by 31 December. The final data export deadline had not been announced when this article was written, so check Zeabur's own notices.
Is 31 December the deadline for every service?
No. Zeabur said not every service will run until 31 December. Plan around each service's own date.
Should we leave managed hosting platforms altogether?
Not necessarily. Managed platforms remain a reasonable choice for many teams. The lesson is to keep data, configuration, domains and secrets portable so that a provider's decision does not become your emergency.
What is the most urgent step if we used Zeabur?
Rotate credentials that were stored in environment variables, as Zeabur's status page advises, and make a tested backup of your data. Then plan the move around your earliest service deadline.