Comparison
Platform vs DIY Kubernetes
Kubernetes gives you every knob. Most teams only need a few of them, and pay for the rest in maintenance.
TL;DR
- Deploy from a repository in minutes, with no cluster to build or upgrade.
- Autoscaling, TLS, and private networking are on by default, not YAML to maintain.
- Your team spends its on-call hours on your product, not on the control plane.
Side by side
What you run, and what runs for you
The same workloads, two ways to operate them.
| Capability | Platform | DIY Kubernetes |
|---|---|---|
| Setup and deploys | ||
| Time to first deploy | Minutes | Days to weeks |
| Deploy on push | Included | Build your own pipeline |
| Zero-downtime deploys | Included | Rollout config per service |
| Preview environments | Included | Not included |
| Operations | ||
| Control plane and node upgrades | Managed for you | Your team |
| Autoscaling | Included | Metrics server and tuning |
| TLS certificates | Issued and renewed | Add-on to install |
| Logs and metrics | Built in | Separate stack |
| Team and cost | ||
| Dedicated platform engineers | Not needed | Usually 1–3 |
| Pricing | Per instance, per second | Nodes plus idle headroom |
| Full control of every cluster setting | Not included | Included |
Why teams switch
What changes when the cluster stops being your job.
Hours back every week
No more upgrade windows, node pool resizing, or chasing deprecated APIs.
Previews for every pull request
Each branch gets its own preview environment without a line of cluster config.
Scaling that just works
Set a minimum and maximum instance count. The platform handles the rest.
Secure by default
Private networking, managed TLS, and encrypted secrets from the first deploy.
Move off your cluster in three steps
Most teams move their first service in an afternoon and finish within a sprint.
- Web service
- Private service
- Worker
- Cron job
- Postgres
- Cache
- 01Pulling image from registry
- 02Importing 14 environment variables
- 03Starting 3 instances
- 04Health check passed
- 05Private network attached
- 06Deploy is live
- Custom domain verified
- TLS certificate issued
- Traffic moved to the platform
- Alerts connected
- Old node pools drained
- Cluster deleted
“We ran our own clusters for three years. Moving to the platform freed two engineers to work on the product again, and our deploys got faster.”
01Can I run my existing container images?
Yes. Deploy from a Dockerfile in your repository or from an image in any registry you can authenticate to.
02What about Helm charts and operators?
Charts map to services, environment variables, and managed databases. Workloads that depend on custom operators may need a different approach, and we will tell you which ones during a migration review.
03Do I lose control over networking?
Services talk over a private network by default. You choose which ones are public, and Enterprise workspaces can connect to their own networks.
04Can we migrate gradually?
Yes. Run both side by side, move one service at a time, and keep the cluster until the last one is switched over.