What Is a Deployment Platform? Types and How to Choose

A deployment platform is the system between git push and a running service. It builds the code, releases it to an environment, injects configuration and secrets, keeps the process healthy and gives you logs and a way back when a release breaks something.

Every platform does some version of that loop, and the differences that matter come later: where the code and data run, whether the platform also creates the database and queue the service needs, and how much you can change once the defaults stop fitting. This guide covers the main types and how to pick between them.

Deployment platform types at a glance

What does a deployment platform do?

The Twelve-Factor App splits the job into build, release and run stages, and that is still a good way to compare platforms:

• Build: turn a commit into an artifact, usually a container image, with dependencies pinned.
• Release: combine that artifact with an environment's configuration and secrets, and record it so it can be rolled back.
• Run: start the processes, route traffic to them, restart them when they fail and scale them with load.

Around those stages sit environments (staging, production, previews for pull requests), observability, custom domains and TLS. The part that varies most is infrastructure: some platforms stop at running your process, and others also provision the database, cache, queue and permissions the process needs.

Shared PaaS

A shared PaaS runs your application on the vendor's infrastructure. You connect a repository, the platform detects the runtime or uses your Dockerfile, and every push becomes a release. Managed Postgres and Redis are usually available as add-ons.

This is the shortest path from repository to URL, and it fits a single web service with a database well. The limits appear when the backend needs more of the cloud: private networking to existing systems, services such as SQS, S3 or Pub/Sub, data residency in a specific account, or a customer security review that asks where data lives. Heroku alternatives and IaaS vs PaaS vs BaaS cover this group.

Frontend and edge platforms

Frontend platforms build static sites and server-rendered apps, serve them from a CDN and run API routes as serverless or edge functions. They make preview deployments per branch the default and handle caching and TLS well.

They are a weaker fit for backends with long-running processes, background workers, scheduled jobs or heavy database connections, which is why many products pair a frontend platform with a separate backend deployment.

Cloud container services

Google Cloud Run, Amazon ECS on AWS Fargate and Elastic Beanstalk run containers or application bundles inside your own cloud account with no cluster to manage. You get the provider's networking, IAM and managed services next to your code.

What you do not get is the rest of the pipeline. Building and pushing images, creating databases and queues, writing IAM policies and keeping staging and production in step usually falls to a CI pipeline and Terraform. Cloud Run vs Fargate compares the two most common choices.

Kubernetes with GitOps

Platform teams often build their own deployment platform on Kubernetes: CI builds images, a GitOps controller such as Argo CD syncs manifests to the cluster, and templates or Helm charts give each service a standard shape. This scales to many services and gives full control over runtime, networking and policy.

It is also a product the platform team maintains. Cluster upgrades, add-ons, templates and the cloud resources outside the cluster are ongoing work, and the internal developer platform guide covers what that usually involves.

Self-hosted PaaS

Open source tools such as Dokku, Coolify and Kamal give you push-to-deploy on servers you control. They are popular for side projects and cost-sensitive products, since a few VMs can host many apps.

You take on the servers: patching, backups, database operations, scaling and failover. That trade works when someone on the team is happy to own it and the load is predictable.

Platforms that deploy into your own cloud

Encore combines an open source infrastructure SDK with a platform that provisions and deploys into your own AWS or GCP account. The application declares its services and infrastructure in TypeScript or Go, and the platform reads those declarations to build the app, provision the matching cloud resources and deploy it, an approach often called infrastructure from code.

A link service with a Postgres table as the source of truth and a Redis cache for hot lookups looks like this, with a migration in links/migrations/1_create_links.up.sql that creates links (code TEXT PRIMARY KEY, url TEXT NOT NULL):

// links/links.ts
import { api, APIError } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { CacheCluster, StringKeyspace, expireInHours } from "encore.dev/storage/cache";

const db = new SQLDatabase("links", { migrations: "./migrations" });

const cluster = new CacheCluster("links-cache", {
  evictionPolicy: "allkeys-lru",
});

const targets = new StringKeyspace<{ code: string }>(cluster, {
  keyPattern: "link/:code",
  defaultExpiry: expireInHours(1),
});

export const resolve = api(
  { expose: true, method: "GET", path: "/links/:code" },
  async ({ code }: { code: string }): Promise<{ url: string }> => {
    const cached = await targets.get({ code });
    if (cached !== undefined) {
      return { url: cached };
    }

    const row = await db.queryRow<{ url: string }>`
      SELECT url FROM links WHERE code = ${code}
    `;
    if (!row) {
      throw APIError.notFound("link not found");
    }
    await targets.set({ code }, row.url);
    return { url: row.url };
  },
);

encore run starts Postgres locally and runs the cache in memory, so the cache-aside path works on a laptop with the same code that runs in production. In an environment on AWS, the database becomes RDS and the cache becomes ElastiCache in your account; on GCP they become Cloud SQL and Memorystore. Encore provisions an IAM role for the service on AWS or a service account on GCP, and compute is Fargate ECS, EKS, Cloud Run or GKE depending on what you pick for the environment.

Each environment deploys from a branch, preview environments spin up per pull request, and production can require an Admin to approve infrastructure changes before a deploy proceeds. Instance sizes, scaling and networking are configured per environment outside the code, and the resources are visible in your own cloud console. The SDK is open source, and encore build docker produces an image you can run anywhere if you later deploy it another way.

An agent asked to add the cache writes the keyspace next to the query that uses it and checks the miss and hit paths under encore run, with no separate Redis setup in another repository.

Best fit: backend teams that want push-to-deploy environments with Postgres, caches and queues running in their own AWS or GCP account, configured from the code that uses them.

If the deployment platform also needs to create the database and queue the service uses, install Encore, declare those resources in application code and deploy into your own AWS or GCP account.

How do you choose a deployment platform?

Work through these questions in order, as the first ones rule out the most options:

1. Whose account does it run in? If customers, auditors or your own data rules require resources in your AWS or GCP account, shared PaaS and frontend platforms drop out for the backend.
2. What infrastructure does the backend need? A single service with Postgres fits almost anywhere. Queues, object storage, scheduled jobs and several services narrow it to platforms that provision those resources or to a cloud plus Terraform.
3. How do environments work? Look for staging that matches production, previews per pull request and a recorded promotion step.
4. How does rollback work? Redeploying the previous release should take minutes, and you should know what happens to database migrations.
5. What can you change later? Instance types, regions, networking and scaling settings should be reachable when the defaults stop fitting.
6. How would you leave? Check whether you keep the data, the images and the cloud resources, or need to rebuild them elsewhere.

Related guides

• Best backend developer platforms
• Managed cloud hosting
• IaaS vs PaaS vs BaaS vs FaaS
• Internal developer platform vs PaaS
• Deployment rollback