Hosting options: Deployment efficiency matters

Most teams pick a deployment platform once and live with it for years. The gap between the fastest and slowest path from Dockerfile to live URL is hours, not minutes, monthly cost can vary three to five times for the same workload, and how fast a code change reaches production once a service exists matters just as much, yet gets talked about far less.

This matters more now: AWS App Runner has moved into maintenance mode (no new customers after April 2026), and Heroku shifted to sustaining engineering in early 2026. Thousands of teams are re-evaluating where to run their workloads.

What "deployment efficiency" actually means

• Setup time. Account creation to a live, HTTPS-reachable URL.
• Update time. Code change pushed to that change serving live traffic on an already-running service. The number most comparisons skip, and the one you live with daily.
• Cost per month. A small, always-on container at modest traffic, not a sleeping free-tier demo.

Setup time is paid once. Update time is paid every deploy, for the life of the service. Ten extra minutes of setup for thirty seconds saved on every redeploy pays for itself within weeks of normal shipping cadence.

Setup time vs. update time: the comparison

Setup assumes a working Dockerfile and repo, account creation to live URL. Update assumes that service already exists, measured from push to live traffic.

Setup and update rankings don't fully agree. Cloud Run and Fly.io take longer to set up but are near the front on update speed once running. ECS pays a structural tax on both, the cost of its health-check-gated safety net. If you ship daily, weight update time more heavily than setup time.

Cost per month: the comparison

List prices mislead. The comparison below is a small, always-on web service: roughly 0.5 vCPU, 512MB to 1GB RAM, modest traffic.

Rule of thumb: flat-rate platforms (Render, standard Fargate) carry fixed overhead a single small service pays in full. Usage-based platforms (Fly.io, Railway, Cloud Run) scale that overhead down with you, which is why they tend to win on cost at small scale.

Reading the trade-off correctly

Fast and cheap now is a cost paid later. Platforms that get you live in five minutes make infrastructure decisions on your behalf, region, scaling, secrets, which is the right trade until you need something the platform doesn't expose. Standard ECS Fargate exists for teams that genuinely need custom task definitions, blue-green deployments, and fine-grained IAM, and are willing to pay in setup time for that control. The mistake is reaching for it before you need it.

What the PaaS comparison leaves out: the hyperscaler bundle

This compares container hosting in isolation. That's wrong once your stack includes a database, storage, a queue, a CDN, and identity, because at that point AWS, Azure and Google Cloud compete on the whole system, not the container.

• One bill, one discount lever. AWS Organizations, Azure Management Groups and GCP Billing Accounts roll multiple projects into one bill, hitting volume tiers faster than any single workload would alone.
• Commitment discounts apply account-wide. AWS EDP, Azure MACC, and GCP CUD are a percentage off total qualifying spend, not one service, something a stack split across separate PaaS vendors has no equivalent to.
• No cross-vendor egress. Traffic between separately-hosted services typically crosses the public internet and gets billed. Intra-account traffic on all three hyperscalers is typically free.
• Single identity model. IAM, Entra ID, or Cloud IAM covers container, database, storage and CI/CD with one permission model and one audit log, instead of one per vendor.
• Simpler compliance scope. Fewer vendors means fewer data processing agreements and sub-processors to disclose for SOC 2, ISO 27001, or HIPAA audits.
• Native AI integration. Azure for OpenAI-on-Microsoft-365, GCP for BigQuery and Vertex AI, AWS Bedrock inside the same VPC. None of the PaaS platforms above offer an equivalent in-network AI story.
• One support relationship. One SLA, one escalation path, instead of a different status page for every vendor in an outage.

This doesn't change the cost or setup-time numbers above for a single small container. It changes shape as the system around that container grows: PaaS wins when the container is most of what you run, the hyperscaler wins once it's one piece of a stack that already includes a database, storage, and identity, because the saving shows up at the account level. Multi-cloud setups are usually about filling a specific service gap, not saving money.

A practical framework

• Prototype or side project: Railway or Render's free tier. Optimise for setup time, cost is near zero either way.
• Small production service, shipping daily: Railway. The sub-minute update time saves real hours over a year of normal shipping.
• Intermittent or spiky traffic: Google Cloud Run. True scale to zero plus fast, instant-rollback revision deploys.
• Latency-sensitive, global users: Fly.io, the only platform here built around regional placement by design.
• Already deep in AWS: ECS Express Mode if you can live with a slower, health-check-gated update cycle. Standard Fargate only once you need its control.
• Running a full stack, not just a container: stay on one hyperscaler. The consolidated bill and zero-egress internal traffic usually beat per-service savings from a best-of-breed PaaS mix.

A note from building InAgentic

We run InAgentic's pipeline on AWS App Runner today, which is why this isn't theoretical for us. Update time matters more than setup time since the pipeline ships several times a week. We're weighing ECS Express Mode's slower rollout against Cloud Run's faster revisions for the parts that ship most often, while keeping always-on services where the setup cost is already paid. The bundling argument favours AWS specifically: our MCP servers, storage, and queueing already share the same account, so a PaaS migration would mean egress that's currently free and losing the single IAM boundary we have. Staying inside one cloud's boundary for services that talk to each other constantly is usually worth more than the per-service saving from spreading them across vendors.

The bottom line

There's no universally correct platform, only the right one for your stage and traffic pattern. The spread is wide enough, in time and in pounds, that it's worth re-running this comparison whenever your traffic changes, your AWS dependency changes, or the platform you're standing on changes its roadmap out from under you.

When building with AI at pace, number of deployment per day will be much higher than in traditional development cycles.