Deploying an application is the moment a working project leaves the developer’s machine and meets a runtime that the developer does not own: a build pipeline, a server, a domain, a database, an environment variable, a log feed, and a way to roll back. The naive answer is “push to a service.” The honest answer is that the deploy is the part of the project the team gets the fewest chances to do well, and the part that decides whether the project is the kind of project the team can ship to a paying customer or the kind of project the team ships to a friend.
The reason “how to deploy an application” is its own question and not just “hosting” is that the deploy is the moment the project becomes real. Before the deploy, the project is a directory. After the deploy, the project is a URL, a database, a process, a log feed, a deploy history, a rollback, and a promise the team is making to the user. The promise is the part the tutorials skip. The promise is the part the post is about.
Table of contents
- The short version
- The five things an “application” actually is
- The decision tree that picks the platform
- The seven stages of a deploy, in the order they should happen
- The four flavors of deploy, ranked for working developers
- The five traps that quietly compound
- The deploy checklist that ships with the project
- How this fits the rest of the stack
- FAQ
The short version
A deploy is a pipeline. The pipeline takes a repository, builds the artifact, runs the artifact on a runtime, points a domain at the runtime, and gives the team a way to roll back. The pipeline is owned by a platform, the build is owned by the team’s code, the runtime is owned by the platform, the domain is owned by the team, and the rollback is owned by the platform. The team’s job is to write the code. The platform’s job is to make the pipeline invisible.
The platform that does the deploy well makes the pipeline feel like a single step. The platform that does the deploy poorly makes the pipeline feel like a job. The team’s mental model is the same in both cases. The team’s weekend is different.
The five things an “application” actually is
A working application is not one thing. A working application is five things, each of which the team has to deploy, configure, and observe. The five things are the same whether the application is a static site, a backend API, a worker, a cron job, or a multi-service architecture. The implementation differs. The five things do not.
The source. The repository, the build command, the test suite, the dependency lock. The source is the part the team owns. The build is the part the team configures. The artifact is the part the platform produces.
The runtime. The process, the operating system, the language runtime, the network, the storage, the scaling rules. The runtime is the part the platform owns. The team writes the application. The platform runs it.
The state. The database, the object store, the cache, the queue, the secrets. The state is the part of the application that has to outlive the process. The platform owns the boring parts of keeping it alive — backups, replication, connection pooling, point-in-time recovery. The team owns the schema, the queries, the migration.
The configuration. The environment variables, the feature flags, the secrets, the build-time configuration. The configuration is the part the team does not want in the build artifact, the log pipeline, or the repository. The platform owns the storage. The team owns the rotation.
The observability. The logs, the metrics, the traces, the deploy history, the rollback. The observability is the part that turns a deploy from a hope into a verification. The platform owns the collection. The team owns the reading.
A team that treats the application as one thing is a team that deploys one thing and then discovers they have five things. A team that treats the application as five things is a team that deploys five things and the project is the kind of project that ships to a paying customer.
The decision tree that picks the platform
A short, opinionated decision tree. The tree is the question a working developer should be able to answer in five minutes. The tree is not a comprehensive platform comparison. The tree is the question that filters the market to the two or three platforms that actually fit the project.
Does the project have a database? If no, the project is a static site, a serverless function, or a single-service API that talks to a third-party API. The platforms that fit are the platforms that excel at static, at serverless, and at single-service APIs. If yes, the platforms that fit are the platforms that own the database as a first-class part of the stack.
Does the project have a long-running process? If no, the project is event-driven, and the platforms that fit are the serverless platforms that bill per request. If yes, the platforms that fit are the platforms that give the process a real process, a real health check, and a real URL.
Does the project have a worker? If no, the project is a single-service application, and the platforms that fit are the platforms that handle a single service well. If yes, the platforms that fit are the platforms that handle a worker as a first-class part of the stack.
Does the project have a cron job? If no, the platform does not need a cron story. If yes, the platforms that fit are the platforms that own the cron job as a scheduled process, not as a thing the team has to wire up by hand.
Does the project have multiple services? If no, the project is a monolith, and the platforms that fit are the platforms that handle a single service well. If yes, the platforms that fit are the platforms that handle multiple services in one console, with one deploy history, and one observability story.
The decision tree is not a list of platforms. The decision tree is a list of the questions the team should be able to answer before the team looks at a single marketing page. The platforms that fit the answers are the platforms the team should evaluate. The platforms that do not fit the answers are the platforms the team should not waste a week evaluating.
The seven stages of a deploy, in the order they should happen
A deploy is not a single step. A deploy is a pipeline of seven stages, each of which the team has to get right before the team can call the deploy “done.” The stages are the same whether the project is a static site, a backend API, a worker, a cron job, or a multi-service architecture.
The source is ready. The repository is connected to the platform. The branch is the one the team wants to deploy. The lockfile is committed. The build command is correct. The platform knows where the entry point is.
The build runs. The platform detects the language, the framework, and the build tool. The platform installs the dependencies, compiles, and produces the artifact. The build is reproducible. The build is cached. The build runs in a clean environment every time.
The artifact is stored. The platform uploads the artifact to a registry it owns. The artifact is the binary, the container image, the static bundle, or the function the next stage is going to run. The artifact is the part the platform owns.
The runtime is ready. The platform has the instance, the operating system, the language runtime, the network, the storage, and the scaling rules. The runtime is the part the platform owns. The application is the part the team owns.
The configuration is loaded. The platform reads the environment variables, the feature flags, and the secrets. The application reads them at runtime. The build artifact does not contain them. The log pipeline does not contain them. The configuration is the part the team owns the rotation of.
The health check passes. The platform hits the health check on the new version, waits for the 200, and only then shifts traffic from the old version to the new one. A failed health check rolls the deploy back. The health check is the part that turns a deploy from a hope into a verification.
The observability is live. The platform collects logs, metrics, and 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 observability is the part the platform owns.
The seven stages are the same for every project. The implementation is different — a static site does not need a health check, a serverless function does not need a build cache, a worker does not need a domain. The seven stages are the shape of the deploy, and the shape is the part the team should be able to draw on a whiteboard before the team picks a platform.
The four flavors of deploy, ranked for working developers
The build-from-source flavor. The platform detects the language, runs the build, starts the service, and gives the team a URL. The team pushes to a branch. The platform watches the build, runs the service, restarts on crash, and surfaces a single deploy history. This is the flavor most working developers actually want, because it removes the Dockerfile without removing the build, the health check, or the rollback.
The container-native flavor. The platform is built around Docker images. The team writes a Dockerfile, builds the image, pushes the image, and the platform runs the container. This is the right flavor for a multi-service architecture, a team that has standardized on containers, and a project where the same image has to run on dev, staging, and production.
The serverless flavor. The platform runs handlers in response to events. The team writes functions, the platform spins up the function per request, and the bill is dominated by invocations. This is the right flavor for an event-driven workload that is spiky and short-lived.
The do-it-yourself flavor. A virtual machine, a Dockerfile, a process supervisor, a reverse proxy, and a deploy script. This is the right flavor for a team that has strong opinions about the base image, the security posture, the network configuration, and every other layer of the stack.
The four flavors are tools, not identities. The team that picks one flavor for every project is the team that is paying for a feature the project does not need. The team that picks the flavor that matches the workload is the team that ships the project on a budget the team can plan around.
The five traps that quietly compound
A short, opinionated list of traps that have actually cost real teams real money on real projects. None of them are dramatic. They are the boring ones.
Treating the deploy as a one-time event. The deploy is not a one-time event. The deploy is a loop the team runs every time a feature ships, a bug fixes, a configuration changes, a dependency updates. A team that treats the deploy as a one-time event is a team that has a deploy script that has not been touched in six months, a deploy history that nobody reads, and a rollback that nobody has tested.
Treating the build as a black box. The build is the part of the deploy the team owns. A team that treats the build as a black box is a team that does not know whether the lockfile is committed, whether the cache is reproducible, whether the build runs the same way on the developer’s machine and on the platform. The team that owns the build is the team that ships the deploy on a schedule the team can plan around.
Skipping the health check. A service without a health check is a service the platform cannot roll out safely. The platform has to either ship a deploy that is risky or force the team to do the rollout by hand. Both are bad. The health check is the part of the deploy that turns a hope into a verification.
Treating the secrets as environment variables. The secrets are not environment variables. The secrets are values that the team rotates, that the platform stores, that the application reads at runtime, and that the build artifact, the log pipeline, and the repository never contain. A team that treats the secrets as environment variables is a team that has a secret in a log line, a secret in a build artifact, a secret in a Slack channel, and a secret in a developer’s .env file.
Picking 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 build story, the health check, the secrets, the rollback, 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.
The deploy checklist that ships with the project
A short, opinionated checklist. The list is the items the team should be able to check off before the team calls the deploy “done.” The list is not a comprehensive deployment guide. The list is the items the cloud tutorials skip.
- The build is reproducible. The build runs the same way on the developer’s machine and on the platform.
- The build is cached. The second build is faster than the first.
- The build runs in a clean environment. The build does not depend on a developer’s local install.
- The artifact is stored. The artifact is in a registry the platform owns.
- The runtime is ready. The instance, the operating system, the language runtime, the network, the storage, and the scaling rules are in place.
- The configuration is loaded. The environment variables, the feature flags, and the secrets are set.
- The health check passes. The platform hits the health check on the new version, waits for the 200, and only then shifts traffic.
- The observability is live. The logs, the metrics, the deploy history, and the rollback are in place.
- The rollback is tested. The team has rolled back at least once, on purpose, before the team had to roll back for the first time.
- The bill is honest. The line items are visible. The team knows what the deploy costs at idle, at peak, and at growth.
The checklist is the part of the deploy the team can draw on a whiteboard. The platform that passes the checklist is the platform the team can ship the project on. The platform that does not pass the checklist is the platform the team is going to spend the first three months building the missing pieces.
How this fits the rest of the stack
A deploy is not the whole stack. The stack is the application, the database, the cache, the object store, the worker, the static site, the domain, the TLS certificate, and the way all of those pieces are observed. The deploy is the moment the application becomes real. The rest of the stack is the moment the rest of the project becomes real.
The services layer is the part of the platform that handles the deploy, the build, 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 application talks to. The static layer is the part that handles the static site, the CDN, and the custom domain the deploy points at. The environment variables are the part that holds the secrets the application reads at runtime.
The shape of the stack matters. A stack that splits the application from the database from the static site from the domain into four different consoles is a stack that punishes the team for having a real project. A stack that lets the team see the whole picture — the application, the database, the storage, the domain, the logs — is a stack that respects the team’s time.
For a team that wants to see the full cost of the deploy before it commits, the RunxBuild hosting calculator 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. The deploy is the part of the project the team is going to think about most, and the calculator is the tool that makes the deploy honest.
FAQ
How do I deploy an application for free?
The free tier is the way most teams start. A static site, a serverless function, or a small API that handles a few requests per minute can ship on a free tier without a credit card. The free tier usually covers the build, the deploy, the domain, and a small amount of traffic. A project that needs a database, a worker, a cron job, or 24/7 availability is going to graduate from the free tier quickly.
What is the difference between deploying an application and hosting an application?
Hosting is the runtime — the instance, the operating system, the network, the storage. Deploying is the act of moving the artifact from the build pipeline to the runtime, behind the URL, behind the health check, behind the rollback. Hosting is the noun. Deploying is the verb. The team that has both is the team that ships.
How long does a deploy take?
A deploy on a modern platform takes minutes from push to live. The build runs in seconds to minutes, the artifact uploads in seconds, the new version starts in seconds, the health check passes in seconds, the traffic shifts in seconds. The team that has a deploy loop under five minutes is the team that ships on a cadence the team can plan around. The team that has a deploy loop under thirty minutes is the team that is going to dread every push.
Do I need a Dockerfile to deploy an application?
Not necessarily. A platform that builds from source can take the repository, run the build, and ship the artifact without a Dockerfile. The Dockerfile is necessary when the build is non-standard (a cgo dependency, a custom linker step, a private package registry) or when the team has standardized on containers. For a standard project, the Dockerfile is friction.
How do I deploy an application with zero downtime?
The deploy loop is push to main, the platform builds the artifact, the platform starts a new instance, the platform hits the health check, the platform shifts traffic from the old instance to the new instance, and the platform tears down the old instance. The loop takes seconds, not minutes, when the platform respects the application as a real process. A failed health check on the new instance rolls the deploy back, and the old instance keeps serving traffic. Zero downtime is a property of the platform, not a property of the developer.
What is the best platform for deploying an application in 2026?
The best platform is the one whose defaults match the workload, whose build respects the artifact, whose health check is honored, whose secrets are scoped, whose rollback is one click, and whose bill stays predictable. The list of platforms that do all six is shorter than the marketing would suggest. The list of platforms that do two of the six and wave at the rest is the rest of the market.