An application platform is a managed runtime that takes your code from a repository, builds it, deploys it behind a real URL, and keeps it running with a database, environment variables, scaling, logs, and rollback behind a single interface. That is the short, working version. The longer version is where the value of choosing the right one actually shows up.
The phrase “application platform” has been stretched to cover almost every layer between “IaaS” and “SaaS,” and the marketing has not made the picture clearer. Some platforms are glorified build servers. Some are full-stack hosts that want to own the database, the worker, the cron job, and the static site in one console. Some are thin wrappers over a virtual machine with a friendly face. The right one for your project is the one whose defaults match your workload, whose bill stays predictable as the project grows, and whose deploy story does not punish you for having a second service.
This post is a developer’s working definition of an application platform, a filter for evaluating one, and a frank look at the line items the cloud taxonomy explainers leave out. It is opinionated. It is not a “what is PaaS” recap — the cloud vendors already have diagrams for that.
Table of contents
- The short version
- What an application platform actually does
- The five things every application platform has to get right
- The four flavors and where each one fits
- The bill that decides the architecture
- A working filter for evaluating one
- The mistakes that quietly compound
- How an application platform fits the rest of the stack
- FAQ
The short version
An application platform is the layer between a repository and a live URL. You push code (or a container image), the platform builds it, runs it behind a domain, gives you a database, holds your secrets, scales the service when traffic grows, and gives you logs and a rollback when something breaks. That is the deal. Everything else is execution.
The “everything else is execution” part is what the cloud taxonomy explainers skip. They tell you that a PaaS removes the need to manage the infrastructure, and they stop. They do not tell you that the same PaaS will quietly charge you for build minutes, idle instances, egress, database connections, and storage that you forgot you had. They do not tell you that a platform that is great for a static site is rarely great for a worker process, and a platform that is great for a worker process is rarely great for a stateful backend. The taxonomy is necessary. The filter is what saves you money.
What an application platform actually does
Strip away the marketing and an application platform is responsible for seven jobs. The list is the same whether the platform is built on bare metal, on Kubernetes, on a serverless runtime, or on a virtual machine with a friendly face. The implementation differs. The job does not.
Source ingestion. The platform connects to a repository, watches a branch, or accepts a container image. The push to main is the trigger. The trigger runs the build. The build produces the artifact. The platform uploads the artifact to a registry it owns.
Build. The platform detects the language, the framework, and the build tool. It installs dependencies, compiles, minifies, bundles, and produces a runnable artifact. The build is reproducible. The build is cached. The build runs in a clean environment every time so that the “works on my machine” excuse stops being an excuse.
Deploy. The platform replaces the previous version with the new one. A health check decides whether the new version is allowed to take traffic. A failed health check rolls the deploy back. A successful health check makes the new version live. The deploy is one step. The rollback is one step. The history is visible.
Runtime. The platform runs the artifact on a runtime that the team does not have to manage. The runtime includes the operating system, the language runtime, the process supervisor, the network, the storage, and the scaling rules. The team writes the application. The platform runs it.
State. The platform gives the application somewhere to keep its data. That is usually a managed database, an object store, a cache, and a queue. The state is the part of the application that has to outlive the process, and the platform owns the boring parts of keeping it alive: backups, replication, connection pooling, point-in-time recovery.
Configuration. The platform holds secrets, environment variables, and feature flags. The application reads them at runtime. The platform never puts them in the build artifact and never writes them to logs. A rotated secret is a rotated secret, not a redeploy.
Observability. The platform collects logs, metrics, and request traces, and exposes them in a way the team can read. The team gets a deploy event, a health check result, a request log, a slow query alert, and a way to roll back. The team does not get a “we will email you when the issue is resolved” message.
A platform that does all seven jobs well is rare. A platform that does three of them well and waves at the rest is the most common kind. The filter below is for sorting one from the other.
The five things every application platform has to get right
These are the five things that decide whether the platform is the one your project will live on for the next three years. None of them is “has a nice dashboard,” because every platform has a nice dashboard. The list is the operational truth.
A clean deploy loop. Push to main, the build runs, the artifact deploys, the health check passes, the new version is live, the old version is kept for rollback. The whole loop should be under five minutes from push to live, and the rollback should be a single click. A platform whose deploy loop is a Dockerfile plus a CI plus a registry plus a manual step is not a platform. It is a pile of parts.
Scoped secrets. The secret lives in the platform. The application reads it as an environment variable. The secret scanner runs in CI. The build artifact does not contain the secret. The log pipeline does not contain the secret. The deploy never asks the developer to paste the secret into a UI field. A platform that handles secrets correctly is a platform you can trust with real data.
A database that does not surprise you. The managed database is the part of the application that has to outlive the process, the deploy, and the person who set it up. Backups, point-in-time recovery, connection pooling, scaling, monitoring, and a sane upgrade path are the minimum. A platform whose database is a managed service you can provision in three clicks and forget about is a platform whose total cost is the line item, not the hidden line item that arrives in month three.
Scaling that matches the workload. A platform that scales on CPU, scales on memory, scales on a queue depth, and scales on a custom metric is a platform that knows the difference between a synchronous API, a background worker, and a cron job. A platform that scales by spinning up more identical copies of the same service is a platform that fits half the workloads and punishes the other half.
Logs you can actually read. The log line is timestamped, scoped to the deploy, scannable in the dashboard, exportable to a real log tool, and retained long enough to debug a problem that surfaced two weeks ago. A platform whose logs are an afterthought is a platform whose first production incident is a Slack thread full of screenshots.
These five are the floor. Everything else is a feature.
The four flavors and where each one fits
The market has settled into four rough flavors of application platform. The flavors are not mutually exclusive — a serious platform usually offers more than one — but the defaults and the pricing reveal which flavor it leans toward.
The static-and-edge flavor. The platform is built for static sites, single-page apps, and the read path of most web applications. The build produces HTML, the CDN serves the HTML, the platform handles a few serverless functions for the write path, and the bill is dominated by bandwidth. This flavor is the right one for a marketing site, a documentation site, a content site, and the front end of a typical SaaS. It is the wrong flavor for anything with a long-running process or a stateful backend.
The container-native flavor. The platform is built around Docker images, container registries, and an orchestration layer that is usually Kubernetes. The team owns the Dockerfile, the platform owns the cluster, and the bill is dominated by instance hours and egress. This flavor is the right one for a multi-service architecture, a team that has standardized on containers, and a project where the same image has to run in dev, staging, and production. It is the wrong flavor for a one-service prototype or a team that does not want to think about images at all.
The build-from-source flavor. The platform detects the language and the framework, runs the build, and starts the service. The team pushes source, not images. The platform owns the build environment, the runtime, and the scaling. This flavor is the right one for a team that wants to skip Docker entirely, that does not have a platform engineer, and that is shipping a single service or a small set of services with shared defaults. It is the wrong flavor for a team that has a custom build pipeline, a monorepo with five services, or strong opinions about the base image.
The serverless-first flavor. The platform is built around functions, event triggers, and per-request billing. The team writes handlers, the platform runs them, and the bill is dominated by invocations and duration. This flavor is the right one for a workload that is spiky, event-driven, and short-lived. It is the wrong flavor for a long-running process, a stateful backend, or a workload that does not fit the event model.
Most teams end up using one primary flavor and one secondary flavor. The static-and-edge flavor handles the front end. The build-from-source flavor handles the API. The container-native flavor handles the worker. The flavors are tools, not identities, and a team that picks one flavor for every problem is usually the team that is paying for a feature they do not need.
The bill that decides the architecture
Every application platform prices on the same five line items. The line items are visible in the marketing and invisible in the architecture conversation, which is why the architecture conversation and the bill rarely agree until month three.
Compute. The cost of the instance hours the platform runs your service on. This is usually the biggest line item, and it scales with instance size, number of instances, and idle baseline. A platform that charges by the hour and a platform that charges by the second look the same in the marketing and very different in the bill. The hour-based platform charges for the time the instance is up, even if no requests are hitting it. The second-based platform charges only for the time a request is being handled.
Build minutes. The cost of running the build pipeline. The build minutes are the easiest line item to underestimate, because the build pipeline runs on every push to every branch, and a team that opens a lot of pull requests is paying for every one of them. A platform with a generous free tier for build minutes is a platform that fits a team that pushes often. A platform with a thin free tier is a platform that punishes the same team.
Database and storage. The cost of the managed database, the object store, the cache, and the queue. This is the line item that grows the most quietly, because the database size grows with the data, the storage grows with the uploads, and the cache grows with the traffic. A platform that shows the database size in the dashboard is a platform that wants you to see the bill before it arrives.
Egress. The cost of bytes leaving the platform. Egress is the line item that nobody talks about and everybody pays, because the public internet charges by the gigabyte and most platforms pass that charge through. A platform that includes egress in the monthly fee is a platform that is hiding the cost in a number. A platform that itemizes egress is a platform that respects the team’s right to know.
Idle baseline. The cost of the platform running even when the team is not deploying. Idle baseline is the sum of always-on services, background processes, and monitoring. A platform that lets the team scale to zero is a platform that respects a project that does not have traffic at 3 a.m. A platform that charges for the instance hours whether or not the instance is doing anything is a platform that does not.
The RunxBuild hosting calculator is useful here because it shows the line items together. The service, the database, the storage, the build minutes, the bandwidth — each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. A platform that hides the line items in a single number is a platform that does not want the team to see where the money goes.
A working filter for evaluating one
A short, opinionated filter for sorting platforms. The filter is not exhaustive. It is the list of questions that have saved me from bad platform decisions.
Can the platform do the boring ops? A custom domain with automatic TLS. A managed database with backups. Environment variables with scoped visibility. Logs that survive a redeploy. A health check that actually checks. A rollback that is one click. If the platform cannot do these out of the box, the team is going to spend the first three months building the missing pieces.
Does the platform explain what is happening? A good deploy UX shows: build started, image created, database connected, route live, logs available. A bad deploy UX shows: deploy queued, deploy running, deploy succeeded (or failed, with no clue why). The team that has to guess what the platform is doing is the team that loses hours to incidents.
Does the platform match the workload? A static site platform is the wrong platform for a stateful backend. A container-native platform is the wrong platform for a one-service prototype. A serverless platform is the wrong platform for a long-running process. The right platform is the one whose defaults match the workload, not the one with the most features.
Does the bill stay predictable as the project grows? A platform that charges by the gigabyte of egress is a platform that punishes growth. A platform that charges by the hour of always-on compute is a platform that punishes underutilization. A platform that charges by the request is a platform that punishes success. The right platform for a project that is going to grow is the one whose pricing is honest about what growth costs.
Does the platform make the second service easier or harder? Most projects do not end with one service. The platform that is great for a single service and a nightmare for a second service is a platform that punishes the team for shipping the right architecture. The platform that makes the second service feel like the first is the platform that fits a team that is going to keep building.
The mistakes that quietly compound
A short, opinionated list of mistakes that have actually cost real teams real money on real platforms. None of them are dramatic. They are the boring ones.
Treating the platform as a build server. A team that uses the platform only for the build and deploys the artifact somewhere else is paying for two platforms and getting the worst of both. The platform should be the deploy target, not a step in someone else’s deploy target.
Letting the database grow without a retention policy. The database is the line item that grows with the data. A team that does not set a retention policy for logs, events, or uploads is a team that is going to look at a bill in month six and not recognize the project. The retention policy is the most boring conversation in infrastructure, and it is the one that decides whether the project stays affordable.
Ignoring the egress line item. A team that puts a 50 MB product photo on the homepage and serves it to every visitor is paying for the egress on every page load. A platform that itemizes egress is a platform that will show the team the number. A platform that hides the egress in a flat fee is a platform that does not want the team to ask.
Scaling by spinning up more identical services. A team that has a synchronous API, a worker, and a cron job, and scales them all by spinning up more copies of the same service, is paying for the wrong shape. The API scales on requests. The worker scales on queue depth. The cron job scales on the schedule. A platform that lets the team configure each one separately is a platform that respects the architecture.
Choosing the platform for the dashboard. A team that picks a platform because the dashboard is the prettiest is a team that is going to be unhappy with the deploy story, the database, the scaling, and the bill. The dashboard is the part of the platform the team looks at. The bill is the part of the platform the team pays for. Optimize for the bill, not the dashboard.
How an application platform fits the rest of the stack
An application platform is not the whole stack. It is the layer that runs the application. The application still needs a database, an object store, a cache, a queue, a CDN, a domain, a TLS certificate, and a way to observe the whole thing. The platform that handles the runtime should make the rest of the stack feel like part of the same conversation.
The services layer is the part of the platform that handles the runtime, the build, the deploy, the health check, the rollback, and the scaling. The database layer is the part that handles the managed Postgres, the backups, the connection pooling, and the point-in-time recovery. The static layer is the part that handles the CDN, the custom domain, and the automatic TLS for the read path. The environment variables are the part that holds the secrets. The logs are the part that lets the team debug the thing they just deployed.
The shape of the stack matters. A platform that splits the application runtime from the database from the static site from the domain into four different consoles is a platform that punishes the team for having a real project. A platform that lets the team see the whole stack in one place — the service, the database, the storage, the domain, the logs — is a platform that respects the team’s time.
For a team that wants to see the full cost of the project before it commits, the hosting calculator is the right tool. The calculator shows the service, the database, the storage, the build minutes, the bandwidth, and the custom domain as line items. The team can see where the money goes. The team can see what happens when the project grows. The team can see what happens when the project graduates from a single service to a multi-service architecture. The architecture conversation is a cost conversation, and the cost conversation is easier when the numbers are visible.
FAQ
What is an application platform?
An application platform is a managed runtime that takes your code from a repository, builds it, deploys it behind a real URL, and keeps it running with a database, secrets, scaling, logs, and rollback behind a single interface. It is the layer between the repository and the live URL. The implementation differs (static-and-edge, container-native, build-from-source, serverless-first), but the job is the same: take code and make it serve traffic without forcing the team to become a platform engineer.
What is the difference between an application platform and PaaS?
A PaaS is a category of cloud service. An application platform is a more specific term for a PaaS that is aimed at developers shipping web applications and backend services, with a friendly default for the boring ops layer (domains, TLS, environment variables, logs, health checks, rollback). The two terms overlap heavily. The difference is mostly one of audience and defaults — an application platform is a PaaS that has decided who it is for.
What is the difference between an application platform and a web host?
A web host is built for static sites and the read path of web applications. An application platform is built for the full stack — the API, the database, the worker, the cron job, and the static site. A web host is the right tool for a marketing site, a documentation site, a blog, or a portfolio. An application platform is the right tool for a project that needs a backend, a database, and a deploy story for the whole stack.
When should I use an application platform instead of running my own servers?
Use an application platform when the team’s time is better spent on the product than on the infrastructure, when the project has predictable traffic patterns, when the team does not have a dedicated platform engineer, or when the project is going to grow past a single service. Do not use an application platform when the workload requires custom hardware, when the compliance posture demands a single-tenant deployment, or when the team has a strong reason to control every layer of the stack.
How much does an application platform cost?
The cost is the sum of five line items: compute (instance hours), build minutes, database and storage, egress, and idle baseline. For a small to medium project, the line items together are usually a few dollars to a few hundred dollars a month. For a large project, the line items together are usually a few hundred to a few thousand dollars a month. The bill that matters is the line-item bill, not the platform’s headline number. The RunxBuild hosting calculator shows the line items together so the team can see where the money goes.
Can an application platform host a database?
Yes. Most application platforms include a managed database as a first-class part of the stack — usually Postgres, sometimes MySQL, MongoDB, or Redis. The managed database is the part of the application that has to outlive the process, and the platform owns the boring parts of keeping it alive: backups, replication, connection pooling, and point-in-time recovery. A team that needs a database should not have to think about the database server; the team should be able to provision a database, point the application at it, and get back to shipping.
What is the difference between an application platform and a BaaS?
A BaaS (Backend as a Service) is built around pre-built backend features — auth, storage, push notifications, serverless functions — that the application calls as a service. An application platform is built around the team’s own code — the team writes the application, the platform runs it. The two overlap in the “managed database” and “managed storage” features, but a BaaS is a kit of parts and an application platform is a runtime for the team’s own code. Most modern projects use a little of both, with the application platform handling the runtime and the BaaS handling the auth and the file storage.