Render and Hangar are close in what they do: web services, background workers and databases, deployed from Git with HTTPS and a deploy on every push. They differ mostly in how you pay and in how each one is configured.
Facts about Render below come from its public documentation as of October 2026. Check render.com/pricing for the current state.
At a glance
| Hangar | Render | |
|---|---|---|
| Deploy from Git | GitHub, GitLab, Bitbucket, Gitea, any public Git URL | GitHub, GitLab, Bitbucket |
| Builds | Automatic (Railpack), Dockerfile, buildpacks | Native runtimes, Dockerfile |
| Prebuilt Docker images | Yes | Yes |
| Compute pricing | Metered by the second on CPU and memory in use | Fixed monthly price per instance type |
| Idle services | Stay running, billed for what they use | Free instances spin down after 15 minutes without traffic |
| Managed databases | PostgreSQL, MySQL, MariaDB, MongoDB, Redis, libSQL | Postgres and Key Value |
| Preview per pull request | Yes | Yes |
| Infrastructure as code | No | Blueprints (render.yaml) |
Pricing
Render sells instances. Each service runs on an instance type with a fixed amount of CPU and memory and a fixed monthly price. Free web services exist, with limits: they spin down after 15 minutes without traffic and take around a minute to wake, a workspace gets 750 free instance hours a month, and a free Postgres database expires 30 days after it is created.
Hangar sells usage. Your plan's subscription becomes usage credit, and CPU, memory, storage and egress are metered by the second on what your services consume. You do not pick an instance size and pay for its headroom. Current plans and rates are on the pricing page, with an estimator.
In practice, a service that is busy all day costs about the same shape on both. Services with quiet hours, staging environments and small workers are where metered billing costs less.
Builds
Render builds with native runtimes for the major languages or with your Dockerfile. Hangar's automatic builder, Railpack, detects the stack with no configuration; Dockerfile builds work the same on both.
Databases
Render offers managed Postgres, with point-in-time recovery on paid plans, and a Redis-compatible Key Value store.
Hangar runs more engines, including MySQL, MariaDB and MongoDB, as services in your project on a private network, with backups you schedule to S3-compatible storage. It does not offer point-in-time recovery.
When Render is the better choice
- You want to describe your whole stack in a file and review it like code. Render's Blueprints do that; Hangar is configured from the dashboard.
- You need point-in-time recovery for Postgres.
- You want a free instance for a demo and can live with cold starts.
When Hangar is the better choice
- Your services have uneven load and you would rather pay for use than for instance sizes.
- You need MySQL, MariaDB or MongoDB managed next to the app.
- Your code is on Gitea, or you deploy from a public Git URL.
- You want spend limits per project that can pause services.
- You want billing in your local currency where Hangar has a local market.
Moving from Render to Hangar
- Create a project and add a service from the same repository. A Dockerfile service moves as it is; for a native runtime service, use the automatic builder and copy the start command.
- Copy the environment variables. Values from a Render environment group become environment variables on Hangar, referenced as
${{environment.KEY}}. See Environment variables. - Create the database, restore a
pg_dumpinto it and updateDATABASE_URL. - Add your domain on Hangar and switch the DNS record once the new deploy is healthy.
Like Render, Hangar sets PORT for your service: it is the domain's container port, 3000 unless you change it. An app that listens on PORT works as it is. See Domains and HTTPS.