Shared Cluster (Being Phased Out)
Shared clusters are being phased out. New projects can no longer be created on shared clusters, and existing shared cluster projects will stop accepting new services from April 1, 2026. All new projects should use Servers.
What Was the Shared Cluster
The shared cluster was Zeabur’s early server offering. In this model, multiple users’ services were deployed on the same Kubernetes cluster, sharing underlying CPU, memory, and network resources. Users didn’t need to manage hardware and only paid for actual resource usage.
Shared Cluster vs. Server
| Feature | Shared Cluster (Being Phased Out) | Server |
|---|---|---|
| Resource Isolation | Multi-tenant, shared hardware | Fully dedicated hardware |
| Billing | Usage-based (vCPU / memory / traffic) | Fixed monthly fee |
| Server Location | Fixed regions (AWS, GCP) | Bring Your Own Host (BYOH), any region |
| Performance Stability | Potential noisy-neighbor effects | Stable and predictable |
| Use Case | Small projects, dev/test | Production, high-reliability workloads |
Why It Was Discontinued
As the server offering matured, Zeabur consolidated the shared cluster into the server architecture to provide better resource isolation and performance guarantees. The usage-based pricing model from the shared cluster era is still referenced in the pricing plans for rate information.
Migrating from Shared Cluster to Server
If your services are still running on a shared cluster, follow these steps to migrate:
- Provision a server — Purchase or register your own server on the Zeabur Servers page.
- Back up your data — Use the Backup & Restore feature to create backups of all stateful services (databases, persistent storage).
- Export your project — Use the Export Project feature to export your project’s YAML configuration.
- Redeploy on the server — Create a new project in the server’s region, import the configuration, and redeploy your services.
- Restore data — Restore the backups from step 2 into the new services.
- Switch DNS — Point your custom domain’s DNS records to the new service’s domain.
- Verify and clean up — Once the new environment is running correctly, remove the old services from the shared cluster.
If you encounter any issues during migration, please reach out on our community forum.