# Zeabur Is Shutting Down: Where Should You Migrate?

> Move your Zeabur application to Kuberns before shutdown. Back up databases and files, replace exposed credentials, test the deployment, and switch DNS.
- **Author**: charan-achari
- **Published**: 2026-10-29
- **Modified**: 2026-10-29
- **Category**: Deployment Guides
- **URL**: https://kuberns.com/blogs/zeabur-is-shutting-down/

---

Zeabur is shutting down. The platform recommends completing migrations by **November 30, 2026**, before shared-cluster services are suspended on December 1. Dedicated servers may stop earlier according to their individual expiration dates, and all remaining services and service data are scheduled to stop or be deleted by December 31.

If your application is running on Zeabur, back up its databases and files, replace credentials stored on the platform, deploy the replacement and test it before switching production traffic. For supported full-stack and backend applications, **Kuberns provides a managed repository-to-production path without requiring your team to operate a VPS or rebuild a deployment platform**.

## TL;DR

- Complete the migration by **November 30, 2026**.
- Check the expiration date of every dedicated server.
- Export the Zeabur project configuration, but back up databases and persistent files separately.
- Replace credentials stored on Zeabur instead of copying the old secret values.
- Deploy the repository on Kuberns and validate the replacement before changing DNS.
- Submit applicable balance-refund and security-claim requests by November 30.

> **Need to move before Zeabur services begin stopping? [Connect your repository to Kuberns](https://dashboard.kuberns.com/) and build the replacement environment while the current application is still available.**

## When Is Zeabur Shutting Down?

Zeabur announced its shutdown on October 17, 2026. A later notice published on October 22 added the recommended migration deadline, refund deadline and data-deletion details. The latest official timeline is:

| Date | What happens | What you should do |
|---|---|---|
| October 17, 2026 | Zeabur announced the shutdown and stopped new dedicated-server and domain purchases | Begin inventory, backups and migration |
| November 30, 2026 | Recommended migration deadline and support-ticket deadline for balance refunds and security claims | Finish the move and submit applicable requests |
| December 1, 2026 | Shared-cluster services are suspended and dedicated-server renewals stop | Production should already be running elsewhere |
| During December | Dedicated servers stop and their data is deleted on their individual expiration dates | Migrate before the expiration date shown for each server |
| December 31, 2026 | All remaining services stop and remaining service data is deleted | Do not use this as the working migration deadline |

The [official Zeabur shutdown announcement](https://zeabur.com/blogs/zeabur-is-shutting-down) confirms the phased December shutdown. Zeabur's later [migration, refund and security-claim notice](https://zeabur.com/blogs/migration-refunds-and-security-claims) recommends completing migration by November 30 and says remaining service data will be deleted when services close.

![Official Zeabur shutdown announcement with the December 2026 service timeline](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/zeabur-shutdown-official.png)

**Treat November 30 as the practical migration deadline.** Dedicated-server users should use the earlier of November 30 or the server's individual expiration date. The safer path is to deploy the application on Kuberns now, restore and verify its data in a separate environment, and keep the current Zeabur deployment available until the final synchronization and DNS switch. That sequence can reduce downtime, although the achievable downtime depends on how the application handles writes, workers and scheduled jobs.

## What Should Zeabur Users Do Right Now?

Do not start by choosing a new provider. Start by preserving everything required to recreate the application.

1. Check whether each workload runs on a shared cluster or dedicated server.
2. Record the expiration date of every dedicated server.
3. Export the Zeabur project configuration.
4. Create independent database dumps.
5. Download persistent volumes and uploaded files.
6. Record environment-variable names and their purpose.
7. Generate replacements for credentials stored on Zeabur.
8. Inventory domains, DNS records, workers, scheduled jobs, webhooks and OAuth callbacks.
9. Deploy and test the replacement before changing production traffic.
10. Transfer domains and submit applicable refund or claim requests.

Zeabur's [official migration guide](https://zeabur.com/blogs/migrate-from-zeabur) explains that moving a service involves more than its source repository. Databases, files, networking, certificates, monitoring and access controls all need a new owner after the platform closes.

> **The clear next action is to preserve the Zeabur state, rotate the credentials and [deploy the repository on Kuberns](https://dashboard.kuberns.com/). Test the new environment while Zeabur is still accessible, then move the data and traffic only after the replacement works.**

## What Must You Move From Zeabur?

A repository may contain the application code, but it usually does not contain production data, uploaded files, secret values or provider configuration. Use this inventory before deciding whether a destination can replace the complete project.

| Component | What to preserve | What the destination must provide |
|---|---|---|
| Application | Repository, branch, runtime, build command and start command | Compatible build and runtime workflow |
| Container image | Registry, image tag and source used to build it | Rebuild or supported image deployment |
| Environment variables | Variable names, purpose and replacement status | Secure production configuration |
| Database | Engine, version, extensions, indexes and verified dump | Compatible database destination |
| Persistent files | Mount path, archive, file count and size | Persistent storage or suitable object storage |
| Background worker | Command, concurrency and dependencies | Supported long-running process |
| Scheduled job | Schedule, command and timezone | Verified scheduled execution |
| Domain | Registrar, DNS provider and current records | New application endpoint and HTTPS |
| Webhooks and OAuth | Provider and current callback URL | Updated production callback URL |
| Internal networking | Service names and private dependencies | Replacement service connectivity |
| Monitoring | Logs, alerts and important historical evidence | Production visibility and alerting |
| Team access | Members, roles and permissions | Recreated access controls |

Do not assume that exporting a Zeabur project also exports database rows or volume contents. Keep configuration exports secure because they may contain sensitive values, and use independent database and file backups for recovery.

If environment configuration has grown inconsistent, follow the guide to [manage production environment variables securely](https://kuberns.com/blogs/environment-variables-in-production/) before adding replacement values to the new deployment.

## Where Should You Migrate From Zeabur?

The correct destination depends on the complete workload, not only whether a platform can build the repository.

| Destination | Best suited for | Main responsibility after migration |
|---|---|---|
| Kuberns | Supported full-stack and complex backend applications needing managed deployment | Application configuration, validation and data migration |
| Another managed PaaS | Teams wanting a similar Git-to-production workflow | Verify every required runtime and managed service |
| Self-hosted PaaS | Teams wanting control over the deployment layer | Operate and secure the underlying servers |
| VPS with containers | Teams experienced with Linux, networking and recovery | Own the entire infrastructure lifecycle |
| Hyperscaler | Teams with established cloud engineering expertise | Design and configure the required cloud architecture |

That service-by-service decision is already visible in the community. In a current discussion from a user [caught by the Zeabur shutdown](https://www.reddit.com/r/SillyTavernAI/comments/1x8d3oz/anyone_else_caught_by_the_zeabur_shutdown/), people compare replacement hosts while also raising persistent-storage, Docker-volume and database requirements. Those dependencies matter more than choosing the provider with the lowest starting price.

![Reddit discussion from a Zeabur user comparing migration destinations after the shutdown announcement](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/zeabur-reddit.png)

Choose a managed platform when you want to preserve Zeabur's repository-to-production experience without becoming responsible for operating servers. Choose a self-hosted platform or VPS only when the team can reliably manage operating-system updates, networking, TLS, backups, monitoring, access control and incident recovery.

For a revenue-generating product, the guide to [choosing production hosting for a SaaS application](https://kuberns.com/blogs/host-saas-app-paying-users/) explains why deployment convenience must be evaluated together with data protection, recovery and operating responsibility.

## Why Kuberns Is a Strong Zeabur Replacement

Kuberns is an **Agentic AI platform for deployment**. It is a strong destination to evaluate when the Zeabur workload is a supported full-stack application, API or backend service and the team wants managed deployment rather than another server to operate.

![Kuberns Agentic AI platform for managed application deployment](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/kuberns-home-page-new.png)

**Repository-based deployment:** Connect the Git provider, select the application repository and branch, and let Kuberns analyze the supported stack and deployment requirements.

**Managed deployment workflow:** Kuberns prepares the application deployment without requiring the team to create and maintain a separate VPS-based delivery platform.

**Production configuration:** Add replacement environment variables through the application environment rather than committing secrets to the repository.

**Deployment visibility:** Review build and runtime information while validating the migrated application.

**Application and resource coordination:** Plan the application, supported datastore and related resources as one production environment instead of treating the repository as the entire system.

Kuberns should still be checked against the complete Zeabur inventory. Confirm the runtime, database engine and version, persistent-file requirements, workers, scheduled jobs, required region, service networking, domain behavior, backup requirements and any data-location obligations before cutover. Kuberns is not being presented as an automatic one-click importer for every Zeabur template or service.

Review [Kuberns production security controls](https://kuberns.com/blogs/kuberns-application-security/) and [how the Kuberns deployment platform works](https://kuberns.com/blogs/what-is-kuberns-the-simplest-way-to-build-deploy-and-scale-full-stack-apps/) while evaluating the destination.

> **Keep the managed deployment workflow without taking on VPS administration. [Connect your repository to Kuberns](https://dashboard.kuberns.com/) and validate the complete replacement before the Zeabur deadline.**

## How to Migrate a Zeabur Application to Kuberns

The safest migration keeps the current Zeabur application available while the replacement is deployed, restored and tested separately. This is not a universal one-click migration because application code, databases, files and external integrations move differently.

### Step 1: Preserve the Existing Zeabur Setup

Export the project configuration and record every service, repository, image, runtime, build command, start command, port, domain and internal address. Capture screenshots of service settings and save the logs needed to diagnose differences in the replacement environment.

Create independent database dumps and persistent-file archives. Record database versions, extensions and important indexes. Store the exports securely because configuration files may contain credentials or internal addresses.

### Step 2: Rotate Stored Credentials

Zeabur's [October security incident report](https://zeabur.com/blogs/october-2026-security-incident) says the attacker read environment variables stored in the platform database and instructs users to replace stored credentials. Generate new database passwords, API keys, deploy tokens, OAuth secrets, JWT secrets, payment credentials, SMTP credentials and webhook secrets as applicable.

Add the replacements to the new environment and revoke the old credentials. If a credential may be actively abused, revoke it immediately and then continue the migration. Do not move an exposed value from one dashboard to another and treat it as secured.

### Step 3: Connect the Repository to Kuberns

Open the [Kuberns dashboard](https://dashboard.kuberns.com/), connect the Git provider, select the repository and branch, and review the application requirements identified by the deployment workflow.

![Create a Kuberns project and connect the application repository](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/create-new-project-in-kuberns.png)

Confirm that the proposed build and runtime settings match the working application. If the Zeabur service depended on a custom image or unusual command, preserve that requirement rather than assuming automatic detection will reproduce it.

The complete walkthrough for [deploying a full-stack application with Agentic AI](https://kuberns.com/blogs/deploy-full-stack-app-with-ai/) provides additional detail without replacing the migration-specific checks here.

### Step 4: Recreate the Required Resources

Map every Zeabur component to a verified destination:

| Zeabur component | Migration approach |
|---|---|
| Git-deployed application | Deploy from the original repository and verified branch |
| Docker-based service | Use the supported Docker workflow after checking image and runtime requirements |
| PostgreSQL database | Create a compatible destination and restore an independent dump |
| Other database or cache | Confirm compatibility or connect a suitable external service |
| Persistent uploads | Move to verified persistent storage or suitable object storage |
| Environment variables | Add newly generated values to the Kuberns environment |
| Custom domain | Add only after testing the temporary deployment endpoint |
| Worker or scheduled job | Verify the required process behavior before recreating it |

![Review the application stack and deployment settings detected by Kuberns](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/project-page-kuberns.png)

Do not force every stateful service into the same migration method. A database dump, volume archive and repository checkout solve different problems.

### Step 5: Restore and Verify the Data

Confirm that the source and destination database versions are compatible. Restore into a test database before the final cutover, then compare tables, row counts, important records, extensions and indexes. Run representative reads and writes through the application rather than checking only that the database process starts.

For a PostgreSQL workload, use the detailed guide to [deploy an application with PostgreSQL](https://kuberns.com/blogs/deploy-app-with-postgresql/) when planning the connection, migration and validation.

Restore persistent files separately and verify that uploads remain available after an application redeployment. Take another backup before the final production synchronization.

### Step 6: Test the Replacement Deployment

Do not change production DNS after seeing only a successful build. Test:

- Homepage and health endpoint
- Login and account creation
- Database reads and writes
- File uploads and downloads
- Payment flow in safe test mode
- Email delivery
- API requests
- Background workers and scheduled jobs
- Webhooks and OAuth redirects
- Logs and error handling

Follow the [web application pre-launch testing guide](https://kuberns.com/blogs/test-web-app-before-going-live/) to verify complete user journeys rather than isolated pages.

### Step 7: Switch Production Traffic

Lower DNS TTL before the maintenance window. If the application accepts writes, pause or restrict them while taking the final database backup and restoring the latest changes. Update DNS only after the replacement environment passes validation.

Replace webhook endpoints, OAuth callbacks and any integration containing a `.zeabur.app` URL. Monitor application errors, build and runtime logs, database activity and external integrations after the switch. Keep the previous environment available temporarily when it is safe and still accessible.

Define a rollback threshold before cutover. The guide to [rolling back a broken deployment](https://kuberns.com/blogs/how-to-rollback-a-deployment/) explains how to make that decision before production is under pressure.

### Step 8: Complete the Zeabur Exit

Confirm that production traffic reaches the replacement, transfer domains purchased through Zeabur, retain final backups and preserve billing and support records. Revoke Zeabur-linked credentials and Git access that are no longer required, and remove obsolete DNS records only after the migration is stable.

Submit account-balance refund and security-incident claim requests separately when applicable. Zeabur recommends submitting both through support by November 30, 2026.

> **Have a full-stack application, database, files or multiple services on Zeabur? [Start the Kuberns deployment now](https://dashboard.kuberns.com/) so the replacement can be restored and tested before production traffic has to move.**

## How Do You Migrate Without Losing Data?

Protecting data requires more than downloading an export immediately before cutover.

- Test every backup before the final migration window.
- Restore a copy into a separate environment first.
- Compare row counts and representative records.
- Copy persistent volumes independently from application code.
- Pause writes before the final database synchronization when required.
- Prevent workers and scheduled jobs from running in both environments.
- Define a rollback threshold before changing DNS.
- Keep the old environment available during validation when possible.
- Do not delete the original Zeabur resources immediately after cutover.

Low-downtime migration may be possible when both environments can run in parallel and the final write pause is brief. Zero downtime cannot be guaranteed for every application because database writes, queues, workers and external callbacks may require coordinated cutover.

> **Avoid these common mistakes:** waiting until December 31, exporting configuration without data, reusing exposed secrets, forgetting persistent files, overlooking webhook and OAuth URLs, running two schedulers simultaneously, changing DNS before testing, or deleting the source environment too early.

## What Happens to Zeabur Domains, Refunds and Claims?

Zeabur says self-service transfers are available for domains purchased through the platform. Begin the transfer early enough to address registrar requirements and verify the destination DNS before the existing hosting stops.

According to Zeabur's October 22 notice:

- Complete service migration by November 30 where possible.
- Submit account-balance refund requests through support by November 30.
- Handle balance-refund requests made after November 30 by email.
- Submit security-incident claims separately by November 30.
- Dedicated-server data is deleted when each server expires.
- Remaining services and service data stop or are deleted on December 31.

Refund eligibility, settlement and payment method depend on Zeabur's review and the account's final charges. Treat the official notice as the authority and do not assume that every account will receive the same outcome.

## Move Your Zeabur Application Before November 30

Zeabur users should treat the shutdown as an active migration, not a future planning task. Secure stored credentials, create independent backups, deploy and validate the replacement, and only then move production traffic.

For teams that want to retain a managed Git-to-production workflow without operating a VPS, Kuberns is the recommended destination to evaluate for supported full-stack and backend applications. Starting now gives the team time to restore data, test integrations and correct migration issues before Zeabur services begin stopping.

[Migrate your Zeabur application to Kuberns with Agentic AI for deployment.](https://dashboard.kuberns.com/)

<a href="https://dashboard.kuberns.com/" target="_blank" rel="noopener noreferrer">
  <img src="https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/CTA_banner.png" alt="Migrate a Zeabur application to Kuberns before the shutdown" style={{ width: "100%", height: "auto", cursor: "pointer" }} />
</a>

## Frequently Asked Questions

### Is Zeabur shutting down?

Yes. Zeabur announced that shared-cluster services will be suspended from December 1, 2026. Dedicated servers stop on their individual expiration dates during December, and all remaining services stop by December 31, 2026.

### When should I migrate from Zeabur?

Zeabur recommends completing migration by November 30, 2026. Dedicated-server users must also check their individual expiration date because their server and its data may be removed before December 31.

### When will Zeabur delete service data?

Zeabur's October 22 notice says dedicated-server data is deleted when each server expires and remaining service data is deleted when all services stop on December 31, 2026.

### Where should I migrate my Zeabur application?

Choose according to the complete workload. Kuberns is a strong managed destination for supported full-stack and backend applications. A self-hosted PaaS or VPS offers more infrastructure control but makes the team responsible for operating and securing the server.

### Can I migrate a Zeabur application to Kuberns?

A supported repository-based application can be redeployed on Kuberns. Databases, persistent files, environment variables, workers, scheduled jobs, domains and integrations must be inventoried and migrated according to their individual requirements.

### Does a Zeabur project export include database data?

Do not assume it does. Treat the project configuration, database data and persistent-volume files as separate migration assets. Create independent database dumps and file archives before moving the application.

### Should I reuse my Zeabur environment variables?

Use the variable names and purposes as a configuration reference, but generate new secret values. Zeabur's October incident report instructs affected users to replace credentials stored on the platform.

### Can I migrate from Zeabur without downtime?

A low-downtime migration may be possible by validating both environments, pausing writes for the final data synchronization and then switching DNS. Zero downtime cannot be guaranteed because it depends on the application's architecture and data behavior.

### What happens to a `.zeabur.app` domain?

A platform-provided `.zeabur.app` address should not be treated as a permanent production domain after Zeabur closes. Move production traffic to a domain you control and update webhooks, OAuth callbacks and integrations that use the old address.

### Can I get a refund from Zeabur?

Zeabur says users should submit account-balance refund requests through support by November 30, 2026. Refund requests after that date must be handled by email. Security incident claims are separate and must also be submitted by November 30.

---
- [More Deployment Guides articles](https://kuberns.com/blogs/category/deployment-guides/1/)
- [All articles](https://kuberns.com/blogs/)