# A Cloud Shutdown Needs a Clean Exit Receipt

> Zeabur will close its hosting services after a second security incident. Customers now need two plans at once: revoke exposed trust, then prove their applications and data can run somewhere else.

- **Author:** Kubilay Tunca
- **Published:** 2026-10-23
- **Category:** For Developers
- **Tags:** Cloud Security, Incident Response, Secrets Management, Business Continuity
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/developers/news/cloud-shutdown-needs-clean-exit-receipt

---

A hosting company can give you a shutdown date. Your database may have an earlier deadline, your domain transfer may take longer than expected, and a credential copied during a breach will not wait for any of them.

That is the problem facing Zeabur customers in October 2026. The deployment platform said an attacker entered its shared cluster, some dedicated servers, and internal systems on 14 and 15 October. The company later confirmed that the attacker read 3,218,965 environment-variable records associated with a platform database holding 321,810 accounts. Zeabur has also announced that services will begin closing on 1 December and that all dedicated servers and shared clusters will stop by 31 December ([Zeabur incident report, 19 October 2026](https://zeabur.com/blogs/october-2026-security-incident); [Zeabur shutdown notice, 17 October 2026](https://zeabur.com/blogs/zeabur-is-shutting-down)).

Independent reports from BleepingComputer and Cybernews confirmed the shutdown and the disclosed scale of the database exposure ([BleepingComputer, 21 October 2026](https://www.bleepingcomputer.com/news/security/zeabur-shutting-down-after-second-security-breach-in-two-months/); [Cybernews, 22 October 2026](https://cybernews.com/news/zeabur-cloud-provider-shutdown-two-breaches-3-million-records/)). Zeabur's investigation remains preliminary, so the precise scope may change. The practical response does not need to wait.

This is not a normal lift from one cloud to another. Customers need to remove the trust that may have leaked, rebuild affected hosts where necessary, move applications and data, and prove that the new system works without quietly depending on the old one. A copied container is not a clean migration when the source host may have been altered. A green homepage is not proof that backups restore, scheduled work runs, or the old API key has stopped working.

The right deliverable is an exit receipt. It should name what moved, what was rebuilt, which credentials were revoked, how the restored data was checked, where traffic now goes, and what access to the former provider remains. Without that record, a rushed migration can carry the incident into the replacement environment.

## What happened, and what remains uncertain

Zeabur's preliminary report describes two routes that met inside its internal network. On one route, an attacker used internal AWS keys and cluster administrator tokens. The shared-cluster administration interface was reachable from the public internet, and the tokens did not expire. Zeabur says the attacker reached shared clusters in nine regions, read service settings and secrets, and ran commands in 865 database services ([Zeabur incident report](https://zeabur.com/blogs/october-2026-security-incident)).

The second route involved an old Google Cloud service-account key. Zeabur says the key could read server initialization settings where root passwords had been stored in plain text. The attacker signed in as root to 101 dedicated servers and added an SSH key to 50 of them. A compromised server then became the place from which a new node joined Zeabur's internal network.

That node could reach the platform database. Between 16:10 and 16:47 UTC on 15 October, Zeabur recorded 29 database connections and 8,903 operations associated with it. The company says those queries reached account and project data as well as environment-variable names and values. Environment variables commonly hold the credentials an application needs to call databases, cloud services, email providers, payment systems, source-control platforms, and AI services.

The database number is large, but the server detail changes the response. A leaked API key can be revoked. Root access to a server creates a different problem because the attacker could change the machine itself. Zeabur classified all 101 affected Google Cloud servers as potentially exposed and potentially carrying unauthorised access mechanisms. Its advice is to back up the data and rebuild the server, which is stronger than changing a password on the existing host.

Zeabur also reports important limits in its evidence. Some cluster logs recorded commands but not their output. Object-access logging was absent for some storage, so the company cannot determine every backup that may have been downloaded. Two other infrastructure providers did not supply operation logs that could settle whether their management tokens had been used. Where access could not be ruled out, Zeabur chose to treat the related material as leaked.

That is a sensible incident-response posture. An absent record proves only that the event was not recorded; it cannot turn an unobserved download into one that never happened. Customers should preserve the same distinction in their own notes: confirmed access, plausible access, checked and not found, or no evidence capable of answering.

The relationship with Zeabur's August incident also requires care. Zeabur says the October credentials were present in a private configuration repository and were not included in the rotation performed after August. It considers a connection between the two incidents plausible, but says it cannot yet confirm how the attacker obtained the repository credentials. The report calls this a hypothesis, not a finding.

The confirmed lesson is narrower. A credential rotation can be described as complete while valid credentials remain in another repository, backup, initialization setting, or retired service. Zeabur corrected its earlier statement that all internal administrator keys had been disabled or rotated. That correction matters because it turns “rotate the keys” from a single command into an inventory problem.

The shutdown is a separate operational decision, though the company says the two incidents exposed shortcomings in security and operations. New dedicated-server and domain purchases have stopped. From 1 December, renewals will be disabled and each dedicated server will stop on its own expiration date. Shared-cluster services will be paused, with manual restarts available for backup, before the final 31 December stop. The data-deletion date and final export deadline had not been announced as of 23 October ([Zeabur shutdown notice](https://zeabur.com/blogs/zeabur-is-shutting-down)).

Do not plan around 31 December alone. A server expiring on 4 December has a 4 December deadline. A domain transfer can depend on an authorization code and registrar processing. A database export is useful only if it can be restored. The calendar contains several clocks, and the earliest one governs each asset.

## Why incident response must come before migration

Migration language encourages copying. Export the data, copy the configuration, deploy the same image, point the domain at the new address. That sequence is efficient when the source is trusted. It is dangerous when the source may contain copied secrets or persistent access.

Suppose a team exports an affected server image and starts it at another provider. The application works immediately. So might an unfamiliar SSH key, a scheduled task added by somebody else, a modified startup service, or a token stored in shell history. The team has moved availability and preserved uncertainty in the same operation.

A clean destination begins from known build inputs. Recreate the operating system from a current image. Build application artifacts from a reviewed source revision through the normal pipeline. Restore business data into that environment after checking the export. Re-enter fresh credentials that were created after the destination was ready. This costs more time than cloning a disk, but it gives the new system a defensible starting point.

Zeabur's own evidence shows why password-only responses fall short. The attacker had root access on affected Google Cloud servers and added SSH keys to some of them. The incident report tells customers to inspect authorised keys, system accounts, scheduled jobs, services, and workloads if they cannot rebuild immediately. Those checks can support containment. They cannot prove that every possible change has been found.

Secret rotation also belongs before broad testing of the migrated application. A deployment with an old database password or cloud key can continue exposing that credential in logs, diagnostics, copied configuration, and failed jobs. Revoke the old credential at its issuing service, create a replacement with narrower authority, put it only in the clean destination, and then test.

Order matters when a credential is shared. Revoking a production key before the replacement path exists can create an outage. Creating a new key while the old compromised host still has access to the secret store can leak the replacement. The safe sequence is usually to contain the suspect path, prepare the clean destination, issue the replacement directly to that destination, switch the workload, verify it, and revoke the old key. Where the old key presents immediate material risk, availability may have to yield to containment.

Zeabur reports an unusually clear example of replacement credentials leaking during response. Its cluster backups held secrets. A new key installed at 15:40 on 15 October entered a 16:00 backup, and the attacker later used it. The backup route had preserved the very trust the response was trying to replace ([Zeabur incident report](https://zeabur.com/blogs/october-2026-security-incident)).

That event should change how teams run rotations. Search backups, image layers, build caches, deployment histories, configuration repositories, service initialization data, and support attachments before declaring the old credential gone. Then keep newly issued credentials out of any still-exposed collection path. A secret manager helps only when the identity allowed to read it and the route used to reach it are also controlled.

The task is larger than environment variables. An application may trust webhooks, signing keys, encryption keys, deploy keys, OAuth applications, session-signing material, package-registry tokens, database roles, cloud service accounts, and domain registrar credentials. Each has a different revocation mechanism. Replacing a value in a deployment screen does not invalidate the value at its issuer.

This is the first half of the exit receipt. For every material credential, record the issuer, old identifier, revocation time, replacement identifier, new scope, destination workload, and verification result. Never copy the secret value into the receipt. The evidence should prove that authority changed without creating one more place where authority is stored.

## A platform is more than the container it runs

Small deployment platforms are attractive because they hide work. A repository becomes a running service, a domain receives a certificate, a database appears, backups run, and logs arrive in one dashboard. The hidden work returns when the platform closes.

A service inventory must therefore describe capabilities rather than product names. “Zeabur app” says where something lived. It does not say what must exist after the move. The replacement list may include a web process, worker, database, persistent volume, object store, scheduled job, private network, domain, certificate, email route, deployment trigger, backup policy, log sink, alert, and budget limit.

Start with one request. A customer asks for a page. The domain name sends the browser to an address. A certificate proves the service's identity. A load balancer or platform router passes the request to a web process. That process reads a database, fetches an object, enqueues work, and emits logs. Every arrow is a dependency that the old platform may have supplied.

The database deserves its own map. Name the engine and version, extensions, roles, character set, collation, time zone, storage size, write rate, and acceptable interruption. Record who writes during migration. Teams need a final synchronization or a deliberate read-only window before switching traffic.

Persistent files often hide outside the database. User uploads may sit on a mounted volume. Generated reports may live on local disk because the first version of the service never needed two replicas. TLS certificates, search indexes, queues, and cache contents may or may not require transfer. Decide by function rather than copying every directory.

Scheduled work is easy to miss because the main application can look healthy without it. A billing reminder, cleanup task, data import, backup, certificate renewal, or report generator might run once a day. The migrated homepage can remain green for 23 hours before anybody discovers that the job stayed behind.

Deployment is another dependency. A new service created manually may work today and fail on the next release because the repository integration, build command, environment selection, health check, or rollback rule was never recreated. The exit receipt should connect the running artifact to a source revision and build. “Copied the container” is weak evidence when the team cannot rebuild it tomorrow.

A useful test is to ask what stops working if the old provider's dashboard disappears now. If the answer includes domain control, source deployment, database credentials, support records, or the only readable copy of a backup, those items come before cosmetic improvements to the new stack.

## Build a clean destination, then prove the data

A migration backup needs more than a file: it needs a successful restore, a consistency check, and a clear point in time. Until those exist, the backup is a hope with a filename.

Create at least one export before changing the source service. Preserve it in storage controlled outside the provider that is closing, encrypt it where appropriate, and record its size and a cryptographic checksum. Keep the checksum beside the backup metadata, not as a substitute for access control. It helps detect an incomplete transfer or accidental change; it does not make exposed data private.

Restore that export into a temporary clean environment. Check that the engine accepts it, expected tables and objects exist, row counts are plausible, recent records appear, and the application can read representative data. Pick checks tied to the service's purpose. A shop might compare order counts and totals for a closed day. A publishing service might open several old articles and their attached images.

Do not chase perfect equality for data that changes while you compare it. Freeze writes, use a transactionally consistent snapshot, or document the expected movement. If the source has 10,003 records and the destination has 10,000 because three arrived after the export, that can be explained. A difference nobody can account for is a stop signal.

Untrusted databases need a content review as well as a count. Zeabur advised affected PostgreSQL users to look for unfamiliar roles, functions, triggers, scheduled jobs, and extensions. That is sensible because database behavior can live in schema objects, not only application code. Restoring every object without review may reproduce an unwanted execution path.

The cleanest route depends on confidence and scale. For a small service, create a fresh database schema from reviewed migrations and import only application data. For a large system, a physical or logical restore may be necessary, followed by an inspection of roles and executable objects. State which path you chose and what it could miss.

Files need equivalent checks. Count objects, compare total bytes, sample downloads, and verify metadata that the application relies on. Watch for case sensitivity, path rules, content types, access policies, and object versioning. A thousand files with matching names can still fail if every private object became public or every content type became a generic binary stream.

Encryption keys require an explicit decision. If a database contains values encrypted under a key that may have leaked, merely moving the ciphertext and old key keeps the exposure alive. Where the application supports it, decrypt under controlled conditions and re-encrypt with a new key in the destination. Where it does not, record the limitation and treat the old key as sensitive until the data can be migrated.

Authentication state deserves similar care. If session-signing or token-signing material may have been read, invalidate existing sessions and require fresh login after the new service starts. Password hashes do not normally require resetting merely because a database was moved, but confirmed or plausible database exposure changes the decision. Consider the hash scheme, retained evidence, account sensitivity, and ability to notify users.

Backups created during the move must not flow back into the suspect environment. Store them under a separate account or project with narrow write and restore identities. Test that the application workload cannot delete the recovery copy. A backup controlled by the same credential as production can disappear with production.

The data section of the exit receipt should show the source snapshot time, export command or job, byte count, checksum, destination, restore result, consistency checks, unresolved differences, encryption-key decision, and recovery-copy owner. Another engineer should be able to repeat the restore without relying on the person who performed it.

## Switch traffic without creating a ghost service

Traffic changes make a migration visible, but they can also leave two live systems accepting different writes. That is how a clean move becomes a reconciliation project.

Lower the domain name system time-to-live before the cutover if you still have time. This value tells resolvers how long they may cache the old address. Reducing it shortly before the switch does not remove copies already cached under the previous value, so make the change at least one old cache period in advance.

Decide which system may accept writes during the transition. The simplest method is a short maintenance window: stop writes at the source, take the final export, restore or synchronize it, verify the destination, switch traffic, and keep the source read-only. Systems that cannot pause need replication or an application-level synchronization plan with a named conflict rule.

A vague dual-write period is rarely a safe shortcut. If both services accept an order with the same customer identifier, which record wins? If an email job runs in both places, which one sends the message? If a payment webhook reaches the old address after the switch, how does the new system learn about it? These are business decisions disguised as plumbing.

Test through the public route after the change. A direct request to the destination address proves that the process answers. It does not prove that the domain, certificate, proxy, firewall, identity callback, webhook, and customer path reach it. Use a harmless transaction that touches the important dependencies and can be removed or clearly marked.

Watch the old environment at the same time. Requests may continue because of cached addresses, hard-coded endpoints, mobile clients, webhooks, partner allowlists, or background workers. Record the remaining traffic and trace it to an owner. Do not delete the source while unexplained legitimate writes still arrive.

Domains need separate custody. Zeabur says self-service transfers are available for domains bought through its platform. Move registrar control to an account the team owns, protect the login, verify the recovery contacts, and record the renewal method. Leaving the domain inside a closing provider preserves a single point of failure.

Email and identity callbacks often contain exact URLs. Update OAuth redirect addresses, single sign-on metadata, payment webhooks, repository hooks, email authentication records, and API allowlists. Test each one. A homepage check cannot reveal a login callback that still points at the old domain path.

Let the destination issue a clean certificate rather than copying a private key from an affected host.

Once the destination is stable, disable the source application. Revoke its deployment hooks and service identities, then remove public routes. Keep only the evidence and exports required by policy or investigation. The old environment should become less capable with each step.

A good cutover receipt includes the traffic-switch time, old and new addresses, source write state, final data point, public-path tests, remaining old traffic, domain custody, callback updates, certificate result, and rollback rule. Rollback should not mean returning to an affected host with exposed credentials. If rollback is necessary, it should return to a known safe state or pause service while the team repairs the destination.

## A practical exit sequence

The dates in Zeabur's notice create pressure, but speed improves when the work has an order. The following sequence separates containment, rebuilding, data assurance, and closure so a team does not perform all four inside one late-night change window.

1. **Name an owner and the earliest deadline for every service.** Record the dedicated-server expiration date, shared-cluster pause date, domain-transfer needs, support case, and any customer commitment. Use the earliest applicable date, not the final 31 December headline.

2. **Preserve evidence before changing the source.** Save relevant audit records, invoices, deployment metadata, recent configuration history, and provider notices in a controlled location. Record the time zone. Do not collect live secret values into the incident folder.

3. **Contain exposed authority.** Restrict or stop suspect workloads, remove unexpected access where immediate action is needed, and identify every credential stored on the platform or affected host. Prioritise keys that can spend money, publish code, administer cloud resources, sign sessions, or read customer data.

4. **Create a capability inventory.** Map web processes, workers, databases, files, queues, scheduled jobs, domains, certificates, repository hooks, private routes, backups, logs, alerts, and billing controls. Assign an owner and destination to each item.

5. **Build from reviewed inputs.** Create a new account or project at the destination, apply strong login controls, use current base images, build from a reviewed source revision, and recreate infrastructure through repeatable configuration where possible. Avoid disk cloning from a host classified as compromised.

6. **Issue fresh, narrower credentials.** Create them at the original issuing services and deliver them only to the clean destination. Separate build, runtime, backup, and administrator identities. Record identifiers and scope, never values.

7. **Export and restore the data.** Keep an independent encrypted copy, record size and checksum, restore into the destination, inspect executable database objects, and perform business-level consistency checks. Resolve unexplained differences before cutover.

8. **Recreate the hidden platform work.** Configure health checks, restart policy, scheduled jobs, backup timing, restore access, logs, alerts, certificates, deployment triggers, and cost warnings. Test a scheduled task now rather than waiting for its calendar slot.

9. **Cut over one controlled path.** Stop or synchronize writes, switch traffic, run a harmless public-path transaction, check callbacks, and watch both environments. Keep the source read-only while caches and partners catch up.

10. **Revoke the old world.** Disable old keys at their issuers, remove repository and OAuth integrations, revoke provider access, close public routes, sign users out where signing material may have leaked, and confirm that old credentials fail. Failure is the desired test result here.

11. **Prove recovery at the destination.** Restore the destination's own backup into an isolated test environment. A successful source export says nothing about the new backup job. Verify that another person can follow the recovery notes.

12. **Close accounts only after the receipt is complete.** Resolve refunds or compensation, retain required records, delete data that no longer has a purpose, and remove the former provider from password managers, identity systems, billing cards, monitoring, and vendor inventories.

For a one-person project, the document may fit on two pages. A larger team may need one receipt per service. The form matters less than the evidence. Each line should answer who did what, when, against which asset, with what result, and what remains uncertain.

Do not hand the whole migration to a coding agent with production authority and hope that speed compensates for missing review. An agent can inventory repositories, draft infrastructure, compare schemas, and run repeatable checks inside a bounded environment. Keep credential issuance, destructive source changes, domain transfer, production traffic, and final revocation behind explicit approval. The Secure Harness is built around that distinction: automation can do the work, while code and policy set the limits of what it may change.

## What the exit receipt should prove

The receipt exists to prevent comforting statements from replacing evidence. “The app is migrated” can mean that somebody saw a page once. “Secrets rotated” can mean that one environment file changed. “Backups done” can mean that a compressed file exists and has never been opened.

For the application, prove the destination serves the expected source revision and that the build can be repeated. Record image digests or release identifiers. Exercise the main user route, worker route, scheduled route, and administrator route. Name anything deliberately deferred.

For data, prove a dated source snapshot became a successful destination restore. Include the consistency checks and their results. State whether the old provider, an affected host, or an old credential can still reach the destination copy.

For trust, prove every material old credential was revoked at its issuer. A configuration diff showing a new value is not enough. Test an old identifier through a safe authentication check where the provider supports it, or retain the issuer's revocation record.

For recovery, prove the new backup can restore without the production workload's identity. Record where the recovery copy lives, who may delete it, how long it is retained, and when the next restore test is due. The migration is a rare chance to correct a backup design that depended on the same account as the live service.

For traffic, prove the public domain, certificate, callbacks, webhooks, and partner routes reach the destination. Then show that the old route is closed or explain the small amount of traffic still arriving. Keep a date for final removal rather than letting a temporary listener become permanent.

For ownership, prove the team controls the registrar, cloud account, billing, source integration, monitoring destination, and recovery contacts. A replacement platform administered through one former employee's personal account is a new exit problem created during the old one.

For uncertainty, preserve honest limits. Perhaps the source provider cannot show whether an object was downloaded. Perhaps your application logs do not retain peer identity. Perhaps one old mobile client may use a fixed address until its next release. Write those facts down with an owner and treatment. Precision about the gap is safer than a green box labelled complete.

This discipline also improves the next vendor decision. Ask a prospective provider how to export data, transfer domains, retrieve logs, scope service identities, separate backups, and close an account. Test the answers with a small service before the platform becomes home to every production secret. Portability belongs in acceptance testing, not in a document opened after a shutdown notice.

The Zeabur report is unusually direct about what went wrong: long-lived plain-text administrator credentials, public administration routes, broad permissions, secrets in backups, incomplete logging, and an earlier rotation that missed relevant keys. Customers did not choose those internal details. They still inherit the recovery work.

That is the uncomfortable contract of managed infrastructure. A provider can carry the operational burden without carrying all of your business risk. Keep independent control of source, domains, backups, credential issuers, and enough deployment knowledge to leave. Running every server yourself is unnecessary; departure simply needs to be a tested engineering operation rather than an act of archaeology.

A shutdown date should start a clock, not a panic. Contain the incident first. Build clean. Restore and test. Move traffic once. Revoke the old world. The final receipt should let a colleague prove that the service runs without the former platform and that the former platform can no longer act on the service.

For more calm, practical security explanations, join the newsletter. It is one email per month.

## Sources

- [Zeabur: Zeabur October 2026 security incident, preliminary report](https://zeabur.com/blogs/october-2026-security-incident), accessed 2026-10-23
- [Zeabur: Zeabur is shutting down, what happens next](https://zeabur.com/blogs/zeabur-is-shutting-down), accessed 2026-10-23
- [Zeabur: Zeabur August 2026 security incident](https://zeabur.com/blogs/august-2026-security-incident), accessed 2026-10-23
- [BleepingComputer: Zeabur shutting down after second security breach in two months](https://www.bleepingcomputer.com/news/security/zeabur-shutting-down-after-second-security-breach-in-two-months/), accessed 2026-10-23
- [Cybernews: Vibe coding platform Zeabur shutting down after two back-to-back breaches](https://cybernews.com/news/zeabur-cloud-provider-shutdown-two-breaches-3-million-records/), accessed 2026-10-23

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._