A managed app platform is a service that runs your application so you do not have to operate the server, the database, the load balancer, the build pipeline, or the SSL termination. The promise is that “managed” means the platform handles the operational work, the team handles the code. The reality is a spectrum — some managed platforms are full PaaS with everything included, some are VPS with a friendlier dashboard, and the marketing language is the same for both. The bill at the end of the month is the only honest comparison.
This post is the unblocker. The first half is what “managed” actually means, in five layers from “we run the server” to “we run everything.” The second half is the questions to ask before signing a contract, the costs that hide behind the marketing, and the moment the team should switch from managed to self-hosted.
The interesting thing about “managed app” is that the term has been stretched to cover almost every level of operational abstraction. The platform that runs your entire stack (build, deploy, database, secrets, CDN) is “managed.” The platform that gives you a VM with a dashboard is also “managed.” The team that picks the second thinking it is the first is the team that ends up running their own database anyway.
Table of contents
- The direct answer
- The five layers of “managed”
- Layer 1: managed VM (least managed)
- Layer 2: managed container
- Layer 3: managed app platform
- Layer 4: managed app platform with database
- Layer 5: full PaaS (most managed)
- The questions to ask before signing
- The costs that hide behind the marketing
- When to switch from managed to self-hosted
- The opinion this post is built on
- FAQ
The direct answer
“Managed” sits on a spectrum:
- Least managed: managed VM. The platform runs the server; the team runs the OS, the runtime, the application, the database, the build, the deploy, the secrets, and the SSL.
- Most managed: full PaaS. The platform runs everything from the build to the SSL, including the database and the CDN. The team writes the code and pushes to git.
The honest comparison is at the same layer. A “managed app platform” that only runs the container is not the same product as a “managed app platform” that includes the database, the build, the secrets, and the CDN. The marketing says “managed.” The bill reflects what is actually included.
The deeper answer is below. The short version: ask the platform what is and is not included, and price the gap.
The five layers of “managed”
The layers, from least to most managed:
Layer 1: managed VM. The platform provides a virtual machine with a public IP, a dashboard, and a console. The team is responsible for the OS, the runtime, the application, the database, the build, the deploy, the secrets, the SSL, and the backups. The platform handles the hypervisor and the physical host. Examples: a basic DigitalOcean Droplet, a basic AWS EC2 instance, a Hetzner VPS.
Layer 2: managed container. The platform provides a container runtime, a build pipeline that converts source code to a container image, and a deploy system that runs the container. The team is responsible for the application, the database, the secrets, the SSL, the build configuration, and the Dockerfile. The platform handles the runtime, the OS, the build, the deploy, and the load balancer. Examples: AWS ECS, Google Cloud Run, Fly.io apps.
Layer 3: managed app platform. The platform provides a build pipeline that detects the runtime, a deploy system that runs the application, a load balancer, an SSL termination, and a custom domain. The team is responsible for the application, the database, the secrets, and the build configuration (Procfile, package.json, etc.). The platform handles the runtime, the OS, the build, the deploy, the load balancer, the SSL, and the custom domain. Examples: Render, Heroku, Railway, Fly.io with a Dockerfile, the RunxBuild platform.
Layer 4: managed app platform with database. Layer 3 plus a managed database. The platform provides a Postgres, MySQL, or MongoDB instance with backups, monitoring, and connection management. The team is responsible for the application, the secrets, and the schema migrations. The platform handles the rest. Examples: Render with a managed Postgres, Heroku with a managed Postgres, Railway with a managed database.
Layer 5: full PaaS. Layer 4 plus managed secrets, managed CDN, managed observability, managed CI, and managed everything else. The team writes the code, pushes to git, and the platform handles every other concern. Examples: Vercel for frontend apps, AWS Amplify for full-stack apps, Google App Engine, the modern “developer cloud” platforms.
The five layers are a spectrum. A team that needs more control picks a lower layer. A team that needs less operational work picks a higher layer. The bill goes up with the layer.
Layer 1: managed VM (least managed)
The classic VPS. The platform gives the team a Linux box with root access, a public IP, and a dashboard. The team is responsible for everything above the hypervisor.
What the team owns:
- OS updates and security patches
- Runtime installation (Node, Python, Go, etc.)
- Process supervision (systemd, pm2, supervisord)
- Reverse proxy (Nginx, Caddy)
- SSL certificate management (Let’s Encrypt, certbot)
- Build pipeline (GitHub Actions, GitLab CI)
- Database installation and maintenance
- Backups
- Monitoring
- Log aggregation
The “managed” in “managed VM” is the hypervisor and the physical host. The rest is the team’s job.
When this is the right answer: when the team has a strong operations background, when the application is unusual enough that no platform can run it as a managed app, or when the cost difference between a managed VM and a managed app platform is large enough to justify the operational work.
When this is the wrong answer: when the team is small, when the application is a typical web service, or when the operational work is not the team’s core competency. Most teams underestimate the operational work by a factor of three.
Layer 2: managed container
The platform provides a container runtime, a build pipeline, and a deploy system. The team is responsible for the Dockerfile, the application, the database, the secrets, and the SSL.
What the team owns:
- The Dockerfile (or equivalent)
- The application
- The database
- The secrets
- The SSL (unless the platform provides it)
- The build configuration (env vars, build args)
What the platform owns:
- The OS
- The container runtime
- The build (source → image)
- The deploy (image → running container)
- The load balancer
- The auto-scaling (if any)
- The health checks (basic)
This is the right answer for teams that want control over the build (a multi-stage Dockerfile, a specific base image, a custom build step) without managing the runtime. It is also the right answer for teams that are migrating from a self-hosted setup to a managed one, because the Dockerfile is a familiar artifact.
The trap: the platform’s “build” is a black box. The team cannot always customize the build, cannot always run pre-deploy hooks, and cannot always access the build logs. The platform’s build works for 90% of projects; the 10% need a different answer.
Layer 3: managed app platform
The platform handles the runtime, the build, the deploy, the load balancer, the SSL, the custom domain, and the health checks. The team is responsible for the application, the database, the secrets, and the build configuration (Procfile, package.json, etc.).
What the team owns:
- The application
- The database (if not provided by the platform)
- The secrets
- The build configuration
What the platform owns:
- The OS
- The runtime (Node, Python, Go, Ruby, etc.)
- The build (source → image, or source → running)
- The deploy (image → running)
- The load balancer
- The SSL termination
- The custom domain
- The health checks
This is the right answer for the typical web service. The team writes the code, defines the build command and the start command, sets the environment variables, and pushes. The platform does the rest. The operational work is minimal.
The trap: the platform’s runtime is the platform’s choice. The team cannot always pick a specific Node version, cannot always install system dependencies, and cannot always run a custom build. The team that needs a specific Node version should pick a platform that lets them set it. The team that needs a custom system library should pick a lower layer.
Layer 4: managed app platform with database
Layer 3 plus a managed database. The platform provides a Postgres, MySQL, or MongoDB instance with backups, monitoring, and connection management. The team is responsible for the application, the secrets, the schema migrations, and the data model.
This is the right answer for the typical web service with a database. The team writes the code, the platform runs the service, the database is one click away, the backups are automatic, and the connection string is an environment variable.
The trap: the platform’s database is the platform’s choice. The team cannot always run a custom Postgres extension, cannot always set the database timezone, and cannot always access the database directly. The team that needs a specific Postgres extension should pick a platform that supports it. The team that needs direct database access should pick a platform that exposes it.
Layer 5: full PaaS (most managed)
Layer 4 plus managed secrets, managed CDN, managed observability, managed CI, and managed everything else. The team writes the code, pushes to git, and the platform handles every other concern.
This is the right answer for teams that want to focus on the product and not on the infrastructure. The trade is cost and flexibility. The full PaaS is the most expensive option, and the team cannot always customize the runtime, the build, the database, or the observability. The team that needs custom runtime or custom database should pick a lower layer.
The modern “developer cloud” platforms (Vercel, Netlify, the modern full-stack PaaS) sit at this layer. The trade-off is the same: the team gives up flexibility for operational simplicity.
The questions to ask before signing
The honest list of questions to ask a “managed” platform before signing a contract:
- What exactly is included in “managed”? The platform’s documentation will list the features. Read it. The list is the answer.
- What is the runtime version, and can I pin it? If the platform picks the Node version and the team cannot pin it, the team is at the platform’s mercy on Node upgrades.
- What is the database, and what are the limits? The platform’s managed database has limits on size, connection count, extension support, and direct access. The limits are the answer.
- What is the build pipeline, and what can I customize? The build pipeline is the platform’s contract with the codebase. The team that needs a custom build step should pick a platform that supports it.
- What is the deploy model, and how do I roll back? The deploy model is the platform’s contract with the production traffic. The team that needs zero-downtime deploys should pick a platform that supports them.
- What is the pricing model, and what are the overage rates? The pricing model is the platform’s contract with the budget. The team that grows fast should pick a platform whose pricing scales linearly, not one whose pricing jumps at thresholds.
- What is the exit story? The exit story is the platform’s contract with the team’s freedom. The team that may want to leave should pick a platform with a clean export path, not one that locks the team in.
- What is the SLA, and what is the support response time? The SLA is the platform’s contract with the production availability. The team that runs a critical service should pick a platform with a real SLA, not a marketing one.
A platform that answers all eight questions clearly is a platform that has thought about the contract. A platform that answers with “we are a managed platform” is a platform that has not.
The costs that hide behind the marketing
The costs that the marketing page does not mention:
- Bandwidth overage. The free tier includes 100GB. The team uses 1TB. The bill is $50.
- Database size. The free tier includes 1GB. The team grows to 100GB. The bill is $30.
- Connection limits. The free tier includes 10 connections. The team needs 100. The bill is $40.
- Build minutes. The free tier includes 100 build minutes. The team deploys 50 times a day. The bill is $30.
- Custom domain SSL. The free tier does not include custom domain SSL. The team needs it. The bill is $20.
- Support response time. The free tier includes community support. The team needs a response in 1 hour. The bill is $200.
The list is not hypothetical. Each item is a real cost on a real platform. The total is the difference between the marketing price and the bill.
A platform that publishes the full pricing (including overages) is a platform that respects the team’s budget. A platform that hides the overages behind “contact us” is a platform that wants to negotiate the bill after the team is committed.
For a sanity check on what a real platform costs, the hosting cost calculator gives a real number to compare against. The cheapest managed platform is rarely the cheapest at scale.
When to switch from managed to self-hosted
The switch from managed to self-hosted makes sense when:
- The team has more than five engineers. The operational work that the platform handles becomes cheaper in-house than at the platform’s rate.
- The application has specific runtime requirements that the platform cannot meet. The team needs a custom Node version, a custom Postgres extension, or a custom build step.
- The platform’s pricing is no longer competitive. The team has grown, the bill has grown, and a self-hosted setup would be cheaper at the new scale.
- The platform has a major outage. The team needs a fallback that the platform does not provide.
- The team is acquired or merged. The new organization has a different platform strategy, and the team’s platform is no longer the answer.
The switch from self-hosted to managed makes sense when:
- The team has fewer than three engineers. The operational work is a tax the team cannot afford.
- The application is a typical web service. The platform can run it as well as the team can.
- The team’s value is in the product, not in the infrastructure. The team should focus on the product.
- The team is launching a new project. The platform’s speed to first deploy is the competitive advantage.
The decision is a function of team size, application requirements, and product value. There is no universal right answer.
The opinion this post is built on
“Managed” is a marketing term that has been stretched to cover almost every level of operational abstraction. The team that picks a “managed” platform without understanding the layer is the team that ends up operating the parts the platform does not manage. The team that asks the right questions before signing is the team that gets a platform whose contract matches the team’s needs.
The right answer is to pick a layer that matches the team’s operational capacity. A small team should be at layer 4 or 5. A team with strong operations should be at layer 2 or 3. A team with a custom runtime requirement should be at layer 1. The layer choice is a function of the team, not a function of the marketing.
The deeper discipline: the platform is a contract. The contract has a price, a feature set, an SLA, and an exit story. The team that reads the contract before signing is the team that does not get surprised by the bill, by the missing feature, or by the lock-in. The team that signs without reading is the team that calls the platform “managed” and then operates the parts the platform does not manage.
The platform is a tool. The product is the product. Pick the platform that lets the team focus on the product, at a price the team can afford, with a contract the team can live with. The cheapest platform is rarely the one that respects the contract.
FAQ
What is a managed app platform?
A service that runs your application so you do not have to operate the server, the database, the load balancer, the build pipeline, or the SSL termination. The promise is that the platform handles the operational work, the team handles the code. The reality is a spectrum — some managed platforms are full PaaS, some are VPS with a friendlier dashboard.
What is the difference between a managed app platform and a PaaS?
A managed app platform is a service that runs the application. A PaaS (Platform as a Service) is a service that runs everything from the build to the SSL. The boundary is fuzzy. Most modern “managed app” platforms are PaaS in the marketing and managed VM in the reality. Read the contract.
What is the cheapest managed app platform?
The cheapest is rarely the cheapest at scale. The free tier is for prototyping. The production tier is for paying customers. The bill at scale is the only honest comparison. Use the hosting cost calculator to estimate the real cost.
Can I migrate from a managed app platform to a VPS?
Yes, in theory. The team exports the code, the data, and the configuration. The team sets up a new server, deploys the code, restores the data, and updates the DNS. In practice, the migration is a project, not a weekend. The platform’s lock-in (proprietary build config, proprietary database extensions) is the real cost of the migration.
When should I switch from a managed app platform to a self-hosted VPS?
When the team has more than five engineers, when the application has specific runtime requirements the platform cannot meet, when the platform’s pricing is no longer competitive, or when the platform has a major outage. The switch is a function of team size, application requirements, and product value. There is no universal right answer.
Should I use a managed app platform or a VPS for a new project?
For a new project with a small team, a managed app platform is the right answer. The operational work is a tax the team cannot afford. For a new project with a strong operations team, a VPS or a managed VM is the right answer. The team can operate the infrastructure, and the operational work is a core competency.