Render, PaaS hosting with per-instance subscriptions

Render, PaaS hosting with per-instance subscriptions

Render takes a GitHub repository, builds it and runs it as a service with a TLS certificate, and offers Postgres as a separate resource. It bills differently from Railway or Fly.io: you pay a workspace plan subscription plus a fixed rate for the instance size you picked, rather than for the CPU cycles you actually burned.

What Render actually does

Render supports several resource types and the differences between them drive the bill. Static sites are static files on a CDN, billed only through bandwidth and build minutes. Web services accept traffic from the internet. Private services answer only inside the region's private network. Background workers have no port and simply run. Cron jobs fire on a cron expression and you pay for the minutes they work. On top of that come Render Postgres, Render Key Value in a Redis-compatible flavour, and Workflows, meaning durable task execution.

The native runtimes are node, python, elixir, go, ruby and rust. Beyond those you get docker for an image built from a Dockerfile and image for an image pulled from a registry. The regions are oregon, ohio, virginia, frankfurt and singapore, and once picked, a region cannot be changed for an existing service.

The platform handles things you would otherwise assemble by hand: TLS certificates for custom domains, zero-downtime deploys, health checks, pull request previews, a private network between services in the same region, and SSH into a running instance. If you want the same on your own server, the starting point is usually a reverse proxy such as Caddy plus a good deal of work of your own.

What Render does not do. A service filesystem is ephemeral and reverts to the image state after every deploy, restart or spin-down. Durability comes from a disk (disk) at 0.25 USD per GB per month, or from a database. A service with an attached disk cannot scale horizontally, so disks and autoscaling exclude each other. There are also no edge functions and no self-hosted variant.

What Render publishes as open source

The platform itself is closed. Only the client tooling is open, and there the licences diverge between the repository and the package registries, so I checked three sources separately.

The command line client lives in the render-oss/cli repository, its LICENSE file carries the full Apache 2.0 text, and the current release is v2.24.0 from 19 August 2026. The Terraform provider, render-oss/terraform-provider-render, is Apache 2.0 as well, version 1.9.1 published in the Terraform registry on 22 July 2026. The MCP server in render-oss/render-mcp-server is Apache 2.0. The AI tooling plugins, render-oss/skills and render-oss/render-plugin-claude-code, are MIT with a 2026 copyright notice.

The most interesting case is the render-oss/sdk repository, which holds clients for three languages. There is no licence file at the repository root. The python and go subdirectories each carry their own LICENSE with the Apache 2.0 text. The typescript subdirectory has no licence file at all, yet its package.json declares "license": "MIT". The upshot is that the same SDK ships under two different licences depending on the language.

Unpacking the published artefacts confirms the divergence. The npm package @renderinc/sdk at version 1.0.0, released on 21 August 2026, declares MIT in the registry, contains 119 files of real compiled code, and not one licence file. The PyPI package render at version 1.0.1, released the same day, has no license field in its metadata, does carry the classifier License :: OSI Approved :: Apache Software License, and genuinely ships render-1.0.1.dist-info/licenses/LICENSE with the full Apache 2.0 text alongside 792 .py files. If your company keeps a dependency licence list, record MIT for the TypeScript client and Apache 2.0 for the Python client, because those are two separate entries.

Two naming traps. The npm package render-cli is not Render's client but somebody else's tool for rendering Jade and Handlebars templates, last released in May 2017 under ISC. Render's client is installed through Homebrew or downloaded from the GitHub releases. The PyPI package render_sdk, in turn, is a compatibility stub declared by the publisher itself with the status Development Status :: 7 - Inactive, which only forces installation of the render package at the same version.

render.yaml, the Blueprint file

Infrastructure as code takes the form of a single render.yaml at the repository root. Below is a working skeleton of a web application with a database, using only fields that genuinely exist in the specification.

services:
  - type: web
    name: api
    runtime: node
    plan: standard
    region: frankfurt
    buildCommand: npm ci && npm run build
    startCommand: npm run start
    preDeployCommand: npm run migrate
    healthCheckPath: /healthz
    autoDeployTrigger: checksPass
    maxShutdownDelaySeconds: 60
    envVars:
      - key: NODE_ENV
        value: production
      - key: SESSION_SECRET
        generateValue: true
      - key: DATABASE_URL
        fromDatabase:
          name: api-db
          property: connectionString
      - key: STRIPE_API_KEY
        sync: false

databases:
  - name: api-db
    plan: basic-1gb
    region: frankfurt
    postgresMajorVersion: "18"
    databaseName: api
    user: api
    diskSizeGB: 15
    connectionPool: pgbouncer

A few fields that are easy to miss. autoDeployTrigger accepts commit, checksPass or off and replaces the deprecated autoDeploy. sync: false means you supply the value by hand in the dashboard and the Blueprint will not overwrite it. generateValue: true tells the platform to generate a random 256-bit secret. maxShutdownDelaySeconds must be an integer between 1 and 300, defaults to 30, and is the gap between the SIGTERM signal and SIGKILL.

Autoscaling and disks are configured in the same service section, but the two cannot be used together.

services:
  - type: web
    name: api
    runtime: node
    plan: pro
    scaling:
      minInstances: 1
      maxInstances: 3
      targetMemoryPercent: 60
      targetCPUPercent: 70
  - type: worker
    name: importer
    runtime: python
    plan: starter
    disk:
      name: data
      mountPath: /var/data
      sizeGB: 10

Autoscaling requires a Pro workspace plan and is disabled in preview environments, where the service always runs a number of instances equal to minInstances. Disk size can only be increased.

Working from the command line and from Terraform

The CLI installs from the Homebrew tap or from the GitHub releases, not from npm.

# install and log in
brew tap render-oss/render
brew install render
render login
render workspace set

# validate the Blueprint file, requires CLI version 2.7.0 or newer
render blueprint validate render.yaml

Inside a continuous integration pipeline the CLI runs in non-interactive mode, so every command needs an explicit service identifier and output format.

# deploy a specific commit and block the pipeline until it finishes
render deploys create "$RENDER_SERVICE_ID" --commit "$GITHUB_SHA" --wait -o json

# query the database without opening an interactive session
render psql "$RENDER_DATABASE_ID" -c "select count(*) from users" -o json

# list services in the active workspace
render services -o text

The Terraform provider covers the same resources, but it spells plan names with an underscore instead of a hyphen, which is a frequent source of errors when transcribing configuration from render.yaml.

resource "render_postgres" "api" {
  name          = "api-db"
  plan          = "pro_4gb"
  region        = "frankfurt"
  version       = "17"
  database_name = "api"
  database_user = "api"

  high_availability_enabled = true

  parameter_overrides = {
    max_connections = "200"
    shared_buffers  = "256MB"
  }
}

Pricing: a workspace subscription plus compute

The bill has three independent parts: the workspace plan subscription, metered charges for bandwidth and build minutes, and a compute rate for every service separately. The workspace plans on the pricing page are Hobby at 0 USD, Pro at 25 USD per month, Scale at 499 USD per month, and Enterprise at a negotiated price. All are described as a price "plus compute", so the subscription alone buys you not a single running instance.

On 23 April 2026 Render rebuilt these plans, and the change is large enough that every older write-up on the web quotes stale numbers. Seat fees disappeared: the former Professional plan cost 19 USD per team member per month and the former Organization 29 USD per member, whereas Pro and Scale now have a flat price and unlimited members. Outbound bandwidth moved the other way: Hobby used to include 100 GB and now includes 5 GB, and Professional used to include 500 GB while Pro includes 25 GB. Overage costs 0.15 USD per GB. Custom domains were unlimited on Professional and are now capped at 15, with each additional one at 0.25 USD per month. Inbound traffic and private network traffic within a region are not metered at all.

The compute rates for web services, private services and workers look like this.

Billing is prorated to the second, so a service switched on for a day and then off costs a fraction of the monthly rate. Cron jobs have per-minute rates and those rates are consistent with the table above: Starter costs 0.00016 USD per minute, which across the 43,200 minutes of a full month gives 6.91 USD, essentially the same as the 7 USD monthly Starter instance.

Build minutes are a separate line item: 500 per month on Hobby, 1,000 on Pro, 5,000 on Scale, then 5 USD per additional thousand. The faster build pipeline costs 25 USD per thousand minutes and requires a Pro plan. A dedicated IP set is 100 USD per month, and AWS Private Link is 30 USD per month for up to three links plus 0.03 USD per GB of outbound traffic across that link.

One clause in the pricing page FAQ tends to be overlooked: the Pro subscription for a given month is waived if the workspace had no services that month, suspended ones included, and no activity. For the Scale plan the subscription is always charged.

The free plan: spin-downs and a database deleted after 30 days

According to the free plan documentation, free instances are available for web services, Postgres and Key Value, regardless of the workspace plan. Upgrading the workspace plan removes none of their limits, because the instance type is set per service.

A free web service spins down after 15 minutes without inbound traffic, counting both HTTP requests and WebSocket messages on existing connections. Waking it on the next request takes about one minute according to the documentation, and the browser sees a loading page during that time. This is the most common surprise on this platform and it disqualifies a free instance as a webhook receiver or a monitoring target. A separate limit is 750 instance hours per workspace per calendar month, and a spun-down service does not consume them. One service running non-stop for 31 days consumes 744 hours, so it fits within the limit, but a second such service does not.

The remaining limits: no disks, no SSH access, no scaling beyond a single instance, no edge caching, no one-off jobs, no ability to receive private network traffic, and blocked outbound ports 25, 465 and 587, that is the whole classic SMTP set. While a service is spun down, requests to /robots.txt receive an automatic disallow-all response and do not wake the process.

The free Postgres database calls for separate caution, because its life cycle ends with data deletion. There is one per workspace, it has a fixed 1 GB of storage, it supports neither backups nor managed connection pooling, and above all it expires 30 days after creation. Once expired, the database becomes inaccessible, you get a 14-day grace period to move it to a paid instance type, and after that deadline Render deletes the database along with its data. A free Key Value instance has 25 MB, keeps data in memory only, and loses it on every restart. If you need a database that survives a quarter, a paid instance is the only option, and the general sizing rules are covered in PostgreSQL.

Render Postgres and the real bill for an application

Since flexible plans arrived, database compute and storage are billed separately. The instance type sets only CPU and memory, while disk space costs 0.30 USD per GB per month and can only be increased, in multiples of 5 GB. The default disk size depends on the tier: 1 GB for Free, 15 GB for Basic, 100 GB for Pro and 250 GB for Accelerated. That means the price in the table is never the full price of a database.

That table exposes a plan selection trap. Basic-4gb gives 2 CPU and 4 GB RAM for 75 USD, while Pro-4gb gives 1 CPU and 4 GB RAM for 55 USD, and only the Pro tier allows high availability. If memory matters more than cores, Basic-4gb is simply more expensive than its neighbour from the higher tier. The point-in-time recovery window depends on the workspace plan and is 3 days on Hobby and 7 days on Pro and above.

Let us price the smallest sensible production setup, meaning a web service plus a database. On the Pro plan: 25 USD for the workspace, 25 USD for a Standard instance with 2 GB RAM, and 19 USD for Basic-1gb together with 4.50 USD for the default 15 GB disk. That is 73.50 USD per month, including 25 GB of outbound bandwidth and 1,000 build minutes. The frugal variant on the Hobby plan: 0 USD for the workspace, 7 USD for a Starter instance and 10.50 USD for Basic-256mb with its disk, so 17.50 USD per month, but with a single team seat, 5 GB of bandwidth and a recovery window cut to 3 days. The variant with headroom: 25 USD for a Pro workspace, 85 USD for a Pro instance, 55 USD for Pro-4gb and 30 USD for the default 100 GB disk, so 195 USD per month. The pricing page does not itemise the cost of a standby instance for high availability, so that line is absent from the bill and I am not guessing its size.

On top of that comes bandwidth above the allowance. An application on the Pro plan sending 100 GB per month pays for 75 GB of overage at 0.15 USD, which is 11.25 USD.

Render against Railway, Fly.io, Vercel, Netlify and Coolify

The core difference lies in the billing model, not in the feature list.

The fixed instance model wins when a service works most of the day. The bill is then known up front to the dollar and does not depend on whether somebody looped a background job. The consumption model wins under uneven load, because an instance sitting idle for 20 hours a day still costs the full rate on Render. The crossover sits roughly where average instance utilisation drops below one third, though that depends on the load profile, so treat the boundary as a rough approximation rather than a calculation.

The drawbacks, plainly. There is no self-hosted variant, so migrating off Render means rewriting the entire runtime layer, and render.yaml cannot be used anywhere else. Cost grows in steps: between a Standard instance at 25 USD and a Pro instance at 85 USD there is nothing in between, so an application that ran 200 MB short of memory jumps to triple the bill. The free plan suits a prototype and learning, but nothing that has to answer within a second or survive a month.

Common mistakes

Treating a free web service as an ordinary endpoint. After 15 minutes of silence the service sleeps, and the first request waits about a minute, so an integration with a payment gateway or an external monitor will return a timeout before the process comes back.

Building anything durable on the free Postgres database. The 30-day deadline from creation is hard, and after the 14-day grace period the data is gone beyond recovery.

Reading the database price from a single column. Basic-1gb is 19 USD of compute plus a separate 4.50 USD for the default 15 GB disk, and Pro-4gb is 55 USD plus 30 USD for the default 100 GB.

Picking Basic-4gb over Pro-4gb at the same amount of memory. The difference is 20 USD per month against the lower tier, along with no high availability.

Basing a budget on numbers from before 23 April 2026. The bandwidth allowance on Hobby dropped from 100 GB to 5 GB, and on the former Professional from 500 GB to 25 GB on Pro.

Installing render-cli from npm. That is another author's 2017 package for rendering templates, not this platform's client.

Setting the branch field in render.yaml while preview environments are enabled. Every preview then builds from that one branch instead of the pull request branch, so you simply will not see your changes.

Attaching a disk to a service that is meant to scale. A service with a disk does not scale horizontally, and disk size cannot be reduced later.

FAQ

Does a free application on Render go to sleep?

Yes. A free web service spins down after 15 minutes without inbound traffic, and waking it takes about a minute according to the documentation. On top of that, a workspace gets 750 free instance hours per calendar month, and they do not roll over to the next month.

What happens to a free Postgres database after 30 days?

It expires and becomes inaccessible. You then have 14 days to move it to a paid instance type. After that period Render deletes the database together with all its contents, and a free database has no backups.

What does a web application with a database actually cost?

On the Pro plan with a Standard instance and a Basic-1gb database it comes to 73.50 USD per month, counting 25 USD for the workspace, 25 USD for service compute, 19 USD for database compute and 4.50 USD for its default disk. The Hobby variant with Starter and Basic-256mb is 17.50 USD per month.

Can Render be run on your own server?

No. Only the CLI, the Terraform provider, the MCP server and the SDK are open, all under permissive licences. The platform itself is closed and has no self-hosted variant, so leaving Render means recreating the runtime layer elsewhere.

When does Railway beat Render?

When a service does nothing for most of the day. Render charges the full instance rate regardless of load, so consumption billing is cheaper for test environments and for jobs that run occasionally. For a service running non-stop the advantage disappears.

Does Render meter inbound traffic?

No. Only outbound traffic to the internet is billed, including HTTP and WebSocket responses and connections initiated by services. Private network traffic between services in the same region, along with log and metric streams to external observability providers, is not metered.