Back to Blog
ArticleOctober 18, 2026

Zeabur Is Shutting Down in 2026: Closure Dates, Security Breaches, Refunds, and Migration Guide

Listen to this article

Uses your device’s available voices. Voice and speed changes apply at the next passage.

Zeabur Is Shutting Down in 2026: Closure Dates, Security Breaches, Refunds, and Migration Guide
On This Page8 sections

Key Takeaways

  • Zeabur is shutting down. Founder Yuanlin Lin informed customers on October 17, 2026 that the deployment platform will wind down. This is a confirmed service-closure announcement, not proof of a formal bankruptcy filing.
  • December 1 is the operational deadline that matters most. Shared-cluster applications are scheduled to be suspended on that date. Dedicated-server renewals also stop, and servers close when their individual terms expire during December.
  • December 31, 2026 is the final shutdown deadline, not a guarantee that individual applications will remain online until then.
  • Security exposure requires action now. Following incidents in August and October, Zeabur has confirmed unauthorized access involving account data, environment variables, tokens, and, in October, some Google Cloud dedicated servers.
  • Back up, rotate credentials, redeploy, and move domains. Account-balance refunds and security-loss compensation are separate requests handled through Zeabur Support.

Is Zeabur Shutting Down in 2026?

Yes. Zeabur announced on October 17, 2026 that it would gradually cease operating its hosting platform by the end of the year. Founder Yuanlin Lin communicated the decision directly to users. The announcement was subsequently reported by INSIDE and other Taiwanese news organizations.

Zeabur is a developer-focused deployment platform that simplified hosting applications, databases, and tools such as n8n. Its appeal came from turning source repositories or templates into running services without requiring developers to administer every part of their infrastructure.

The shutdown does not mean every Zeabur-hosted application went offline on October 17. It means the company has published a staged retirement schedule. Customers must move their workloads before the deadlines that apply to their particular services.

As of October 18, 2026, there is no basis in the cited announcements for calling this a court-confirmed bankruptcy or claiming a published insolvency filing. The accurate description is an announced platform wind-down.

Zeabur Shutdown Timeline: Every Confirmed Deadline

DateWhat happensWhat customers should do
August 27–28, 2026The first major security incident occurred and was disclosed.Revoke potentially exposed credentials and review provider activity.
September 22, 2026Zeabur confirmed its AI Hub would not return and explained its balance-refund arrangements.Check AI Hub credits separately from other account balances.
October 14–15, 2026Zeabur identified another security incident; its public status updates documented wider access.Rotate secrets again, investigate unauthorized usage, and back up data.
October 17, 2026The founder announced the platform wind-down. New dedicated-server and domain purchases stopped.Inventory applications, domains, databases, volumes, and subscriptions.
December 1, 2026Dedicated-server renewals stop. Shared-cluster services are scheduled for suspension, with manual restart available for backup.Complete critical cutovers before this date, preferably earlier.
December 1–31, 2026Dedicated servers are scheduled to close as their individual terms expire.Migrate each server before its specific expiration time.
December 31, 2026All remaining dedicated servers and shared clusters are scheduled to close.Treat this as the final cutoff, not a migration target.

The founder's notice also says that data-deletion dates, the last opportunity to export data, and Zeabur Support's own closing date have not yet been finalized. Do not confuse the lack of a published deletion date with a guarantee that production services or backups will remain accessible.

Why Is Zeabur Closing? Security Failures, Complexity, and Market Pressure

Zeabur identified three overlapping reasons for its decision: the impact of repeated security incidents, growing architectural and operational complexity, and uncertainty about its long-term differentiation as AI lowers the barrier to deployment.

The August 2026 Breach

In its September 7 incident report, Zeabur said an attacker began on August 27 by exploiting a vulnerability in a publicly accessible user service. The attack crossed multiple trust boundaries, eventually reaching a production database. The company confirmed unauthorized reads of account information and project environment variables containing third-party API credentials, database passwords, and other sensitive values.

The technical lesson is important: a compromised application can become a broader platform incident when network boundaries, service permissions, and administrative credentials are insufficiently isolated. Zeabur's report described weaknesses in credential handling, privilege scoping, network isolation, and detection.

The October 2026 Incident

The founder dated the second intrusion to October 14 (UTC). The official incident status page, updated on October 15 (UTC), initially described unauthorized access to PostgreSQL and MySQL services on deprecated shared clusters. A subsequent update expanded the known scope: the attacker had read access to the platform database, and some dedicated servers hosted on Google Cloud had also been accessed without authorization.

Zeabur listed potentially exposed material including service environment variables, account information, API tokens, and zSend API keys. It revoked certain compromised credentials, rotated internal signing credentials, and restricted public SSH access to affected Google Cloud dedicated servers while investigating.

Confirmed access is not the same as confirmed misuse of every credential or compromise of every customer application. The publicly disclosed scope was still being investigated. Nevertheless, credentials that could have been read should be considered untrusted until revoked.

Commercial and Operational Factors

The founder's account also cited the platform's approximately three-and-a-half-year history, increasing maintenance costs from repeated architectural changes, and a growth bottleneck despite demand from AI-assisted development and automation workloads. These statements explain management's decision; they do not establish a published cash-balance figure or prove insolvency.

A second-order consequence is that security remediation and shutdown migration compete for the same engineering capacity. For customers, this increases the value of exportable data, independently controlled domains, infrastructure-as-code, and tested recovery procedures.

Which Zeabur Services Are Affected?

Zeabur service or assetKnown positionMigration implication
Shared-cluster applicationRunning services scheduled for suspension starting December 1.Move before December 1; manual recovery after suspension should be only a contingency.
Dedicated serverRenewals stop December 1; shutdown follows the individual expiry date during December.Find the exact expiry date and transfer data before it.
PostgreSQL, MySQL, MariaDB, MongoDBDatabases and their credentials must be independently backed up and secured.Export a portable dump, check versions, and run a restore test.
Persistent volumes and uploaded filesSource code alone does not contain runtime-generated files.Download and verify every attached volume and external asset.
Domain registered through ZeaburThe closure notice says self-service transfers out are available.Move registrar control as well as hosting; allow time for transfer restrictions.
Third-party domain pointing to ZeaburDomain registration remains with the original registrar.Change DNS records to the new host and preserve email-related records.
Zeabur AI HubSeparately discontinued in September following the August incident.Migrate AI API calls directly to another supported provider.

Do not assume that deleting a Zeabur project, transferring a domain, and terminating billing are the same operation. They address different assets and must be verified separately.

Immediate Security Checklist: What to Do Before Migrating

The best response has two tracks running in parallel: contain the credential risk and prepare a verified copy of each service.

  1. Inventory every project. Record repository, branch, runtime version, build and start commands, custom domains, service ports, scheduled jobs, databases, volumes, webhook endpoints, and external integrations.
  2. Revoke old API keys at their issuing providers. Prioritize AI model APIs, payment processors, object storage, cloud accounts, GitHub integrations, and email services. Creating a replacement key does not automatically invalidate the original.
  3. Rotate database passwords at the actual database server. Updating a Zeabur environment variable alone does not change a PostgreSQL or MySQL account password. Synchronize the real password change with the application configuration and redeployment.
  4. Regenerate Zeabur access tokens and zSend API keys. The official October advisory explicitly recommends replacement; previously issued zSend keys were being revoked.
  5. Review dedicated-server access. For Google Cloud servers, the advisory recommends changing the root password and removing unfamiliar SSH keys, especially ones labeled zeabur-pentest.
  6. Audit third-party usage and billing. Look for unexpected model-token consumption, payment events, storage access, API calls, sign-ins, and configuration changes starting before the known disclosure dates.
  7. Export logs and preserve evidence securely. Keep relevant billing records, security alerts, timestamps, and support-ticket identifiers for incident investigations or compensation claims; never place live secrets into a support ticket.
  8. Avoid copying compromised secrets into the new environment. Reuse application settings only after replacing the credentials they contain.

Credential rotation may briefly interrupt production traffic. Where supported, issue a new key, deploy the replacement, validate requests, then revoke the old key immediately. For high-risk credentials, revoke first and accept a controlled outage if necessary.

How to Back Up Zeabur Before Shutdown

A Git repository captures application code, not the entire live service. A reliable migration package should include code and image versions, database dumps, user-uploaded files, persistent volumes, deployment configuration, secret names, DNS records, and scheduled-task definitions.

Step 1: Use Zeabur's Backup Interface

Zeabur's backup and restore documentation describes downloadable volume backups and online database backups. In the service dashboard, open the Backup tab, create a backup where supported, and download it outside Zeabur.

The documentation says online database backups include standard exports: PostgreSQL backups are generated with pg_dumpall, MySQL/MariaDB backups use SQL, and MongoDB backups contain BSON data. It also states that Zeabur ordinarily retains backups for seven days. A backup visible in the dashboard is therefore not a durable off-platform archive.

Keep at least two independently stored copies and record the backup timestamp, file size, checksum, and restoration result. Backup availability can depend on service type, permissions, and the incident-related state of the platform.

Step 2: Export PostgreSQL to a Portable Format

When direct database access is available, PostgreSQL's native tools allow a fresh logical export. The following example uses environment variables configured locally, rather than embedding passwords in a command or committing them to Git:

bash
pg_dump --dbname="$SOURCE_DATABASE_URL" \
  --format=custom --no-owner --no-acl \
  --file=zeabur-app.dump

pg_restore --dbname="$TARGET_DATABASE_URL" \
  --no-owner --no-acl --single-transaction \
  zeabur-app.dump

SOURCE_DATABASE_URL and TARGET_DATABASE_URL must be supplied securely in the shell or secret manager. The target database should be created first. Use compatible client versions and account for required PostgreSQL extensions, roles, locale settings, and access restrictions.

Important: a Zeabur-generated PostgreSQL .sql backup made with pg_dumpall is not a custom-format pg_dump archive. Restore that plain SQL with psql, after reviewing role and database-creation statements and the permissions offered by the destination:

bash
psql --dbname="$TARGET_ADMIN_DATABASE_URL" \
  --set=ON_ERROR_STOP=1 \
  --file=zeabur-postgres-backup.sql

Managed PostgreSQL providers often restrict superuser and role creation operations, so a full pg_dumpall script may require adaptation or per-database exports. A successful process exit alone is not enough: verify table counts, row counts, application queries, and writes.

Step 3: Export Files, Jobs, and Supporting Services

For containerized applications, check paths such as upload directories and mounted volumes rather than assuming they are included in the repository. Preserve Redis data only if it contains durable state, queues, or sessions that the service needs; a disposable cache usually does not require migration.

Record cron schedules, queue worker concurrency, webhooks, OAuth redirect URLs, and external storage buckets. A website can load normally while these hidden integrations remain broken.

Step 4: Restore to a Staging Environment

Restore backups into a new environment before production DNS changes. Confirm database schema and migrations, file access, login, account permissions, background jobs, and representative transactions. Keep the old environment available during a bounded rollback window where possible.

Migrating n8n from Zeabur: The Encryption-Key Trap

n8n users face a particularly costly migration mistake: transferring the database without its encryption key. Encrypted credentials cannot be read by a new instance that generates a different key.

According to n8n's backup and restore guidance, a complete self-hosted backup includes the .n8n data folder and any external PostgreSQL database. The .n8n configuration or a separately configured N8N_ENCRYPTION_KEY is essential for recovering encrypted credentials.

  • Preserve the existing N8N_ENCRYPTION_KEY or original configuration key securely during restoration; do not publish it or replace it casually.
  • Back up SQLite data if the deployment uses SQLite, or the external PostgreSQL database if configured.
  • Export workflows and credentials as an additional recovery path, but recognize that CLI exports alone omit important instance state such as users and execution history.
  • Match application versions and review compatibility before restoring, especially when encryption-key rotation or database migrations have changed stored formats.
  • Reconfigure webhook base URLs, OAuth callbacks, reverse proxy settings, workers, queue storage, and credentials after the move.
  • Disable the old scheduler or instance when enabling the new one to prevent duplicate workflows and payments.

After confirming credentials decrypt correctly on the restored instance, rotate upstream third-party credentials affected by the breach. Do not solve the exposure by arbitrarily replacing n8n's master encryption key, which can make existing credentials unreadable.

Best Zeabur Alternatives in 2026: Choose by Workload

There is no universal replacement because Zeabur combined application deployments, stateful services, and infrastructure management. The best destination depends on whether the application needs a persistent process, traditional filesystem access, managed databases, or only static hosting.

AlternativeBest suited toMain migration consideration
RailwayNode.js/Python applications, Docker services, APIs, PostgreSQL, n8nConvenient multi-service workflows; verify database backup configuration, volume usage, and network charges.
RenderWeb services, background workers, managed PostgreSQL, conventional app hostingReview instance sleep behavior where applicable, regions, persistent disk options, and pricing.
Fly.ioContainerized applications with region-specific deployment requirementsRequires more involvement with machine sizing, stateful volumes, and network configuration.
Cloudflare Workers / PagesStatic sites, Astro frontends, edge APIs, lightweight request-driven applicationsNot a drop-in replacement for an always-running Docker container, n8n worker, or traditional persistent filesystem.
VPS + Docker Composen8n, WordPress stacks, multi-container applications, predictable infrastructure controlThe operator takes responsibility for patching, backups, monitoring, firewalling, and disaster recovery.

Recommendation by scenario: an Astro static site is often easier to move to Cloudflare Pages than to another container host; a standard Node.js API with PostgreSQL usually fits Railway or Render; a complex multi-container automation stack may be simpler to reproduce on a VPS with Docker Compose. For workloads requiring relational databases, plan the application and database migration as one change.

For implementation details, consult the Cloudflare Astro deployment guide and Railway's PostgreSQL backup and restore guide. These choices are architectural recommendations, not claims that every application can migrate without changes.

A Seven-Step Zeabur Migration Plan with Minimal Downtime

  1. Classify urgency. Treat shared-cluster workloads as pre-December-1 priorities. For dedicated servers, put the individual expiration date on the deployment calendar.
  2. Build a clean target environment. Reproduce runtime versions, ports, secrets, storage, networking, database extensions, and process types. Enable backups and monitoring before cutover.
  3. Perform a trial restore. Validate a production-derived database backup, persistent uploads, key application paths, logins, webhook endpoints, and administrative workflows on a staging URL.
  4. Prepare DNS. Where the DNS provider permits, lower affected record TTLs ahead of the move, for example to 300 seconds. Preserve MX, SPF, DKIM, DMARC, DNSSEC, and verification records as relevant; check apex, www, and subdomains separately.
  5. Control write activity. For transactional databases, schedule a brief maintenance window or use a tested replication/change-capture process. Take a final delta backup or synchronize pending writes before promoting the destination. Avoid having two independent production databases accept writes simultaneously.
  6. Switch production traffic. Point DNS or the reverse proxy to the new environment, verify TLS certificates and canonical hostnames, and watch error rates, payment flows, queues, and latency. Keep the original URLs where possible to minimize search-engine disruption.
  7. Finish the exit. Confirm backups can be restored independently, transfer Zeabur-registered domains, disable old workloads, revoke obsolete access, document new recurring costs, and file refund requests.

SEO-Specific Risks During a Website Migration

Moving hosting providers does not require changing the domain or URL structure. Preserving existing paths, status codes, canonical tags, sitemaps, and robots rules helps avoid unnecessary organic-search volatility.

After DNS cutover, test real pages and assets, especially SSR routes, image processing, redirect rules, robots.txt, sitemap.xml, and APIs. Look for unexpected 404, 502, and 503 responses and accidental noindex directives. A 301 redirect is necessary when a URL actually changes, not merely because its server changes.

A hosting migration that preserves URL identity is ordinarily simpler for SEO than a domain migration. The largest preventable search risks are downtime, blocked crawlers, broken server rendering, and changing URLs without a redirect plan.

Zeabur Refunds, Domain Transfers, and Compensation

The shutdown announcement distinguishes between remaining account-balance refunds and security-incident loss compensation. Both are handled through Zeabur Support, but they are separate claims. Include the relevant account, project or service identifiers, balance details, and supporting evidence, while keeping raw API keys and payment credentials out of tickets.

Customers who bought domains through Zeabur were told that self-service outbound domain transfers are available. Start the transfer early and verify registrar transfer restrictions, domain unlock status, authorization codes, registrant details, and DNS continuity. A domain at a third-party registrar generally does not need to be transferred simply because Zeabur hosting is closing.

Separately, the September AI Hub announcement says unused paid AI Hub balances were returned to Zeabur credit, with a cash-refund request option. That earlier policy should not be confused with the broader October platform-shutdown refund process.

Refund eligibility, payment method, processing time, compensation outcomes, and final export deadlines should not be assumed until Zeabur confirms them for the relevant account. Keep copies of invoices, balance screens, payment confirmations, and support correspondence. Customers facing unresolved payment disputes may also consult their card issuer about applicable dispute procedures and deadlines.

Frequently Asked Questions

Did Zeabur go bankrupt?

Zeabur announced a voluntary operational wind-down on October 17, 2026. The announcement does not establish that a court declared the company bankrupt or that an insolvency filing exists. Use shutting down rather than bankrupt unless separate verified legal records become available.

Is Zeabur still working today?

The shutdown announcement did not immediately switch off all hosted services. Availability varies by service, incident remediation, and the published closure timetable. Check the live Zeabur status page and the individual project dashboard rather than assuming every deployment is healthy.

Can a Zeabur website stay online until December 31?

Not necessarily. Shared services are scheduled to be suspended on December 1, while dedicated servers can expire on different dates throughout December. December 31 is the final platform-wide deadline, not a promised uptime date.

Are Zeabur customer API keys and passwords safe?

Zeabur confirmed unauthorized reads involving environment variables and other sensitive account or token information. The safe action is to revoke and replace potentially exposed credentials at the issuing providers, then audit associated activity. The announcement does not prove that every account suffered malicious usage.

Can domains purchased from Zeabur be moved elsewhere?

Yes. The October announcement says self-service outbound domain transfers are available. Actual transfer timing can depend on registrar and registry rules. Export DNS records and maintain authoritative DNS continuity during the process.

Can an existing Zeabur project be migrated automatically?

Application code and Docker configurations may be portable, but database data, volumes, infrastructure-specific settings, OAuth callbacks, secrets, and domain records still require validation. Treat AI-generated migration scripts as drafts requiring a restore test and human review, especially before destructive commands.

Can users still request refunds?

Zeabur says it is accepting account-balance refund requests and security-incident compensation claims through Support. They are separate processes. Their final outcomes, deadlines, and eligibility may differ by account.

Conclusion

Zeabur's closure is confirmed, and December 1, 2026—not December 31—is the practical planning deadline for many users. The two disclosed security incidents make this more than a routine hosting move: account holders must safeguard credentials while preserving databases, persistent files, domains, and production continuity.

Start with a complete project inventory and an off-platform, successfully restored backup. Then revoke exposed credentials, deploy a clean replacement, test every critical workflow, and switch traffic before the applicable service cutoff. Finish by confirming domain control and submitting any refund or compensation claim through Zeabur Support.

Share this article

Referenced Tools

Browse entries that are adjacent to the topics covered in this article.

Explore directory