TL;DR

• What you get: one upload per photo, and every thumbnail, WebP version and watermarked copy from a URL like …/image?w=400&h=400&fit=cover&format=webp.
• Who it's for: shops, marketplaces and apps that show user or product photos, and don't want to run an image server.
• Time: about 10 minutes in the dashboard.
• Cost: no listed fee for transforms. You pay storage for originals and cached variants (about $0.011 per GB-month at the standard rate).

Every product photo on your site needs four or five sizes: a thumbnail, a card, a full view, a social preview. Most teams either resize on upload with a script that breaks the day design changes a size, or run an image server they then have to patch and scale. Both cost you time, and slow pages cost you sales.

In this guide you'll store each photo once in Hubfly space Storage and ask for any size, format or watermark straight from the URL. Your designer can change the card size tomorrow without anyone re-processing a single file.

Try it on Hubfly space → (free tier, no card needed)

What the feature does

Hubfly space Storage is S3-compatible object storage. When you register an uploaded file as a managed asset, it gets delivery links and an image endpoint. Add query parameters to that endpoint and the service renders the variant on the first request, then caches it in your bucket.

Full reference: Storage assets and images.

Walkthrough: a product image pipeline in 10 minutes

1. Create a Storage project

In the dashboard, click Create Project, name it (for example shop-media), pick the Storage platform and choose a region. A Storage project keeps your buckets, keys and delivery settings apart from your app's containers, so you can give the app a key that only touches images.

2. Create a bucket

Click Create bucket and call it product-images. A bucket is the folder your app will write to; keeping product photos in their own bucket lets you scope a key to just that bucket later.

3. Upload a photo as a managed file

Click Upload files, drop in a photo and leave Managed file ticked. That tick is what registers the file as an asset with delivery links and an image endpoint. A plain S3 object doesn't get them automatically.

4. Choose who can see it

Open the file and go to Delivery. New assets start as Protected: every link needs the asset's access key or a temporary share link, and a request without one gets 401 access key required. For catalogue photos that anyone may see, switch Link access to Public. Keep customer uploads (IDs, invoices, private galleries) on Protected, and give them random object keys: a Protected viewer page still shows the file name and size to anyone with the link.

5. Build your image URLs

Your asset URL looks like https://<storage-node>/product-images/<asset-id>. That address opens a viewer page. For image bytes, add /image and your parameters:

https://<storage-node>/product-images/<asset-id>/image?w=400&h=400&fit=cover&format=webp

The Transform & Cache tab has a form for every parameter and a Preview transformation button that builds the URL for you.

Use the URLs in a responsive image tag so each screen downloads only what it needs:

<img
  src="https://<storage-node>/product-images/<asset-id>/image?w=800&format=webp"
  srcset="https://<storage-node>/product-images/<asset-id>/image?w=400&format=webp 400w,
          https://<storage-node>/product-images/<asset-id>/image?w=800&format=webp 800w,
          https://<storage-node>/product-images/<asset-id>/image?w=1600&format=webp 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Blue ceramic mug on a wooden table">

For a social preview card, ask for the exact shape: ?w=1200&h=630&fit=cover&format=jpeg&quality=85.

6. Add a watermark

Add text and placement to the same URL. wm_x and wm_y go from 0 to 1, so 0.9/0.9 puts the mark near the bottom-right corner:

…/image?w=800&h=500&fit=cover&format=webp&wm_text=ACME%20Shop&wm_opacity=0.6

For a logo instead of text, upload it in Transform & Cache, click Save allowed watermark, and use wm_key. Only a saved key works in public URLs, so a public link can't pull in any other file as a watermark.

7. Check the cache

The same tab lists every cached variant with its size and expiry, and lets you delete one. Identical URLs reuse the cached file instead of creating a new variant. On each image you can keep variants for the bucket default, a custom number of hours, or forever.

Doing it from your app

The same flow works through the Storage API. Here are the routes from the API reference, each under https://api.hubfly.space/api/v1/projects/:projectId/storage/:

The upload session matters: your browser code never sees your S3 secret, only a URL that expires.

What can go wrong

1. The image comes back at full size. You added parameters to the viewer page or the /media link. Transforms only work on the /image path.
2. "unsupported or repeated image parameter". The service rejects unknown and duplicate parameters. Don't pass your own tracking or cache-busting query strings to image URLs.
3. "fit requires both dimensions" or a size error. cover, contain and fill need w and h; each side must be 1–4,096 px and the output 16 MP or less.

A fourth one shows up later: each image allows 100 distinct transforms per UTC day. Pick a fixed set of sizes (say 400, 800, 1600) instead of the exact pixel width of every screen.

Limits and pricing, honestly (October 2026)

• Transforms: no listed fee. Variants are stored under .hubfly-images/ and count toward your storage like any other file.
• Storage rate: the pricing page lists standard storage at $0.00001536 per GB-hour. Over a 730-hour month that's 0.00001536 × 730 = $0.0112 per GB.
• Example: 2,000 product photos at 1.5 MB is 3.0 GB. Four WebP sizes at an assumed 80 KB each (WebP product shots usually land between 20 and 100 KB) add 2,000 × 4 × 80 KB = 0.64 GB. Total 3.64 GB × $0.0112128 ≈ $0.04 a month. A full 100 GB project quota would be about $1.12 a month.
• Bandwidth: delivery is metered and shown under Activity & usage, but no per-GB rate is published. Check your Billing page before you serve heavy traffic.
• Free tier: you can sign up and build this without a card; the free tier also includes 360 compute hours a month for your app.
• Security: traffic uses HTTPS, but object bodies are not encrypted at rest. Encrypt sensitive files in your app first.

Who it's not for

• You need AVIF or animated output. Formats are WebP, JPEG and PNG, and animated sources use the first frame.
• You generate a different size per user or viewport. The 100-per-day limit will bite; resize on upload instead.
• You need private photos in long-lived embeds. Protected links rely on an access key or short share links (15 minutes to 24 hours in the dashboard). A dedicated media CDN with signed URLs may suit you better.

Takeaway

Upload once, describe the size in the URL, and let the cache do the rest. Keep a short list of sizes, keep private files Protected, and watch storage rather than per-image fees.

Read next: Isolated SaaS tenants with sub-accounts · Deploy a docker-compose.yml as-is · Best Heroku alternatives in 2026

Go further on Hubfly space

• Run the shop itself on Hubfly space Cell: deploy your app and database from a Compose file next to your images.
• One bucket per customer: if you sell a SaaS, give each tenant its own space with sub-accounts.
• Video too: the same Storage project turns uploads into HLS streams at 360p to 1080p (video docs).

Start free on Hubfly space, 360 hours included →

Your Heroku bill is a dyno plus a database, and you want to know where to move and what it will cost. Heroku still works, and your app on it is fine today. But in February 2026 Heroku said it is moving to a "sustaining engineering" model, centered on upkeep and dependable operation, with new features no longer the priority, and it stopped offering Enterprise contracts to new customers (Heroku's announcement). Card-paying customers keep the same pricing. Still, if you're starting something new, or your bill keeps growing, it's a good moment to look around.

The problem: most "Heroku alternatives" lists give you a "starting at" price per platform and stop there. That's not what you pay. You pay for a web service plus a database, and sometimes a workspace fee on top. This guide prices the same small app everywhere, so the numbers compare.

Try it on Hubfly space: free tier, 360 compute hours a month, no card needed.

TL;DR

• What you get: the monthly cost of the same small app (one always-on web service with 512 MB of RAM plus a Postgres database) on Heroku and 7 alternatives, with every price linked to the vendor's own pricing page (prices as of 19 October 2026).
• Who it's for: anyone running a side project, an internal tool or an early SaaS on Heroku who wants to know where to go and what it will cost.
• Time needed: 10 minutes to read, about 15 minutes to move a small app.
• Short answer: for a managed database, Render and DigitalOcean cost about the same as Heroku. For the lowest bill on a managed platform, Fly.io and Hubfly space land around $7.50 a month, but you run Postgres in a container yourself. If you're happy to be your own ops team, Coolify on one Hetzner server is the cheapest per gigabyte.

The reference app

To compare Heroku alternatives fairly, every price below is for the same setup, the one most Heroku apps actually are:

• 1 web service, always on, about 512 MB of RAM (the size of a Heroku Basic dyno).
• 1 Postgres database, small, with at least 1 GB of storage.
• 730 hours a month (a full month, always on).
• Lowest-priced region where a platform charges differently by region.

Why this matters: a price per container alone hides the database, which is often half the bill. And a "free" plan that sleeps after 15 minutes isn't the same product as an always-on one. So the main table is always-on, and free tiers get their own section.

The comparison table (always on, per month)

All prices were read on the vendors' official pages on 19 October 2026, in USD, before tax. Prices change. Click through before you decide.

How the usage-based numbers are worked out

Hubfly space bills per resource: \(0.004 per vCPU-hour, \)0.002 per GB of RAM per hour, and $0.00001536 per GB of storage per hour (pricing). For one always-on dedicated container with 1 vCPU, 512 MB of RAM and 5 GB of disk:

• CPU: 1 × \(0.004 × 730 h = \)2.92
• RAM: 0.5 GB × \(0.002 × 730 h = \)0.73
• Disk: 5 GB × \(0.00001536 × 730 h = \)0.056
• Total: $3.71 a month per container

Two of those (web and Postgres) come to $7.41. The Postgres volume adds 1 GB on Balanced storage (1.5× the base rate): 1 × $0.00001536 × 1.5 × 730 = $0.017. Grand total: $7.43. The Stack Composer's Monthly Estimate prices each service as you set it up, before you deploy (screenshots below). Drop each container to 0.5 vCPU and the total falls to about $4.51.

Railway bills what your services actually use, per second: $0.00000386 per GB of RAM and $0.00000772 per vCPU (pricing). A 730-hour month is 2,628,000 seconds. Assume each service holds 0.5 GB of RAM and averages 0.05 vCPU (a quiet app):

• RAM: 0.5 × \(0.00000386 × 2,628,000 = \)5.07 per service
• CPU: 0.05 × \(0.00000772 × 2,628,000 = \)1.01 per service
• Two services: $12.17, plus a 1 GB volume at $0.16 = about $12.33

The Hobby plan's $5 minimum is included in that, not added. A busier app costs more; one that idles at 200 MB costs less. That's the point of usage pricing, and also why you can't know the bill in advance.

Fly.io prices above are for Ashburn (iad), one of its two lowest-priced regions. Fly lists higher prices elsewhere; a 1 GB machine is $6.70 in Ashburn and $7.73 in Frankfurt (pricing).

Free tiers: what you get, and the catch

If your app must answer instantly at 3 a.m., none of the free tiers is for you. Pay for always-on, on any platform.

Where each platform wins

A fair comparison says where the others are better.

Heroku is still the original "push and forget" experience, with a large add-on marketplace. Card customers keep the same prices. Stay if your app is stable and the bill doesn't hurt; the main risk is fewer new features from here on.

Render works the most like Heroku: managed Postgres, the same web-service model, and a free tier for experiments. You pay a little more than Heroku for the same setup, and $0.15 per GB after 5 GB of bandwidth on Hobby (pricing).

DigitalOcean App Platform matches Heroku's price with a cheaper web container ($5) and a $7 dev database. Bandwidth overage is only $0.02 per GiB. Good if you already use DigitalOcean.

Railway has a visual project canvas and bills by the second for what you really use. Great for spiky or idle apps. Harder to predict a monthly bill.

Fly.io wins on regions: you can run the same app close to users on several continents, at $3.69 for a 512 MB machine in Ashburn (pricing). Its managed Postgres is the most expensive line in this table, so most small apps run their own.

Koyeb has the cheapest small container here ($2.68 for 512 MB). Its managed Postgres starts at $29.76 a month, so it's cheapest when the database lives elsewhere.

Coolify on Hetzner gives you the most server for the money: 2 vCPU and 4 GB of RAM for $6.49. Coolify itself is free to self-host. But you're the ops team: OS updates, backups, monitoring and the 3 a.m. disk-full alert are yours. One more catch on 19 October 2026: Hetzner's cost-optimized page listed the CX23 as "currently unavailable".

Hubfly space lands next to Fly.io on price ($7.43 always on, $4.51 at half a vCPU), with no per-seat, per-project or custom-domain fee. You can also set a monthly budget cap per project, so a runaway app stops instead of surprising you. Where it's weaker today: Postgres runs as a container you manage, and Hubfly doesn't yet document database backups or snapshots. If you need to run in many regions at once, Fly.io is the stronger pick.

Moving a Heroku app to Hubfly space in about 15 minutes

Here's the path for the reference app: a web service and Postgres.

1. Create a project. In the dashboard, click Create Project, pick Cell, choose a region and, under Advanced Options, set a Monthly Budget Limit (for example $10). A budget cap means a bug can't run up a big bill.

2. Describe your app in a Compose file. Heroku's Procfile and add-ons become two services. Replace your-image with your app's image, or deploy from Git (Hubfly builds from a root Dockerfile or detects your stack from package files).

services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: notes
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-h", "127.0.0.1", "-U", "app", "-d", "notes"]
      interval: 5s
      timeout: 3s
      retries: 10
  web:
    image: your-image
    environment:
      DATABASE_URL: postgres://app:change-me@{{service:db.host}}:5432/notes
    ports:
      - "80:80"
    depends_on:
      db:
        condition: service_healthy
volumes:
  pgdata:

Replace change-me with a long random password (for example from openssl rand -hex 24) and keep the real value out of Git: set it in the service's environment variables in the dashboard.

Why the volume: it keeps your database files when the container restarts or redeploys. Without it, every update would wipe your data. Why {{service:db.host}}: Hubfly fills in the database's private address, so the app never goes over the public internet to reach Postgres.

3. Import and check the price. Click Create → Compose Stack, open the YAML tab, paste the file and click Import YAML. The Monthly Estimate shows the cost before anything runs. Both services start on the free shared tier.

4. Choose always-on, if you need it. Click the web service, open Resources and switch Service tier to Dedicated (Production). The default is 1 vCPU, 512 MB and 5 GB, with 24x7 On. The estimate updates right away.

5. Deploy. Click Deploy Stack. The volume is created, Postgres deploys first, then the web service. The whole stack is up in under a minute.

6. Give it a public URL. Open the web service, then Network → Add Domain → Auto Endpoint and click Create Subdomain. You get an HTTPS address like your-word.eu1.hubfly.app within seconds. The ports: "80:80" line only gives a raw TCP address; the Auto Endpoint is what gives you HTTPS. Add your own domain the same way under Custom Domain.

7. Move your data. Dump from Heroku with heroku pg:backups:capture and heroku pg:backups:download, then open a HubTunnel to the new database (hubfly tunnel create --project <project-id> --container <db-container-id> --port 5432 --local 15432) and restore: pg_restore --no-owner --no-acl -h 127.0.0.1 -p 15432 -U app -d notes latest.dump. Switch your DNS when the data is in.

What can go wrong

1. The app returns 502 Bad Gateway. Heroku sets PORT for you and your app listens on it. On Hubfly, the app must listen on 0.0.0.0 and on the port you expose. An app bound to 127.0.0.1 gives a 502. Fix: bind to 0.0.0.0 (full fix).

2. ports: "80:80" gives you a TCP address, not a website. Importing a Compose file with ports creates a raw TCP endpoint on tcp.eu1.hubfly.app. For HTTPS, add an Auto Endpoint or a custom domain as in step 6.

3. The web service starts before the database is ready. Don't count on depends_on: condition: service_healthy to hold the web service back. Add a connection retry with backoff in your app, so it keeps trying until Postgres accepts connections, and again after any restart (health checks explained).

Bonus: Hubfly doesn't read a Procfile. Put your start command in the Dockerfile or in Configuration → Process Settings.

Takeaway

• Want a managed Postgres and no ops? Render (about $13) or DigitalOcean (about $12). Same price range as Heroku.
• Want the lowest bill on a managed platform, and can run Postgres in a container? Fly.io ($7.53) or Hubfly space ($7.43, or $4.51 at half a vCPU), with a budget cap on Hubfly.
• Want the most server per dollar and don't mind ops? Coolify on Hetzner ($6.49 plus IPv4).
• Bill depends on traffic and you like per-second pricing? Railway.
• Just need the cheapest container, with the database elsewhere? Koyeb ($2.68).

Read next: Heroku vs Render vs Railway vs Hubfly: 4 prices for one app + Postgres, Deploy a docker-compose.yml as-is: 8 platforms compared and Gate your app on a Postgres migration job.

Go further on Hubfly space

• Ship a new version to 10% of users first with a weighted load balancer: canary releases guide.
• Keep uploads and images out of your app container with S3-compatible Storage buckets and on-the-fly image resizing.
• Lock an admin panel behind a login at the edge with Identity Access, no code changes.

Moving from Heroku? Paste your stack into the Stack Composer and see the monthly estimate before you deploy anything. Start free on Hubfly space.

Your app starts, tries to reach the database, and crashes because Postgres is still waking up. Or worse: everything looks "healthy", but Redis is rejecting every request because of a password typo. A health check is a small command that answers one question, over and over: is this service actually ready to do its job? Get it right and you can see when a service is truly ready, broken ones are easy to spot, and your users stop seeing errors during deploys.

In this guide you'll add working health checks to a web app, Postgres and Redis, deploy them as one stack, and learn the three mistakes that make a health check say "all good" when it isn't.

Try it on Hubfly space: the whole stack runs on the free shared tier (360 hours a month, no card needed).

TL;DR

• What you get: a Compose file with checks for Postgres (pg_isready), Redis (redis-cli ping | grep -q PONG) and a web app (wget, shown with nginx), deployed in dependency order.
• Who it's for: anyone running more than one container, from side projects to small production apps.
• Time: about 15 minutes. The stack deploys in about a minute.
• The three traps: redis-cli exits 0 even when the password is wrong; pg_isready can pass while Postgres is still running its first-boot scripts; and the image may not contain the tool your check calls.

What a health check is (and what it isn't)

A health check is a command that runs inside the container on a timer. Exit code 0 means healthy. Anything else counts as a failure. After a set number of failures in a row, the container is marked unhealthy.

Every check has four timing settings:

Two things a health check does not do on its own:

• It doesn't restart anything. A container that fails its check keeps running. Restart policies react to a process exiting, not to a failed check.
• It doesn't fix your app's startup. It tells other services, and you, when something is ready. Your app should still retry its database connection for a few seconds on startup, because networks blink.

Why it matters: without checks, "the container is running" is the only signal you have, and a running container can be completely useless.

Step 1: Write a check for Postgres

db:
  image: postgres:16-alpine
  environment:
    POSTGRES_USER: shop
    POSTGRES_PASSWORD: change-me
    POSTGRES_DB: shop
  volumes:
    - pgdata:/var/lib/postgresql/data
  healthcheck:
    test: ["CMD-SHELL", "pg_isready -h 127.0.0.1 -U shop -d shop"]
    interval: 5s
    timeout: 3s
    retries: 5
    start_period: 20s

Why each piece is there:

• pg_isready ships with the Postgres image, so there's nothing to install. It asks the server "are you accepting connections?" and exits 0 when the answer is yes.
• -h 127.0.0.1 is the important bit. On first boot, the official image starts a temporary Postgres that listens only on a local socket while it runs your init scripts. A plain pg_isready checks that socket and can pass too early. Forcing TCP with -h 127.0.0.1 waits for the real server.
• start_period: 20s gives a fresh database time to initialize before failures count.
• The volume keeps your data when the container restarts or redeploys. Without it, every update would start from an empty database.

Step 2: Write a check for Redis (and avoid the exit-0 trap)

cache:
  image: redis:7-alpine
  environment:
    REDIS_PASSWORD: change-me
  command: ["sh", "-c", "exec redis-server --requirepass \"$REDIS_PASSWORD\""]
  healthcheck:
    test: ["CMD-SHELL", "REDISCLI_AUTH=\"$REDIS_PASSWORD\" redis-cli ping | grep -q PONG"]
    interval: 5s
    timeout: 3s
    retries: 5

This is the syntax for the Hubfly space Stack Composer. In a local docker compose file, write $$REDIS_PASSWORD instead (see "What can go wrong" #2).

Most examples online use redis-cli ping on its own. That check passes even when Redis is refusing you. Run it against a password-protected Redis and look at the exit code:

redis-cli prints the error and still exits 0. Your check would say "healthy" while every real request fails. The fix is to check for the actual answer: | grep -q PONG exits 1 unless Redis really replied PONG.

Why REDISCLI_AUTH instead of -a password: redis-cli reads the password from this variable, so it doesn't show up in the process list or the shell history.

Why exec in the command: it makes redis-server the main process, so it receives stop signals directly and shuts down cleanly.

Step 3: Write a check for your web app

Add a small /health route to your app that returns 200 when it can reach what it needs. Then check it from inside the container:

web:
  image: your-app:latest
  healthcheck:
    test: ["CMD-SHELL", "wget -q -O /dev/null http://127.0.0.1:3000/health || exit 1"]
    interval: 10s
    timeout: 3s
    retries: 3
    start_period: 15s
  depends_on:
    db:
      condition: service_healthy
    cache:
      condition: service_healthy

Two things to get right:

• Use a tool the image actually has. Alpine-based images include wget (from BusyBox); many, like redis:7-alpine, have no curl, while nginx:alpine has both. Run which curl wget in the container to be sure. Slim Debian images (python:3.13-slim, node:22-slim) have neither. For those, call your runtime instead, for example python -c "import urllib.request,sys; urllib.request.urlopen('http://127.0.0.1:3000/health', timeout=2)". Distroless and scratch images have no shell at all, so build a tiny check into your app binary.
• Check 127.0.0.1, not your public URL. The check runs inside the container. Testing the public URL measures your proxy and DNS, not your app.

depends_on with condition: service_healthy sets the order: db and cache first, web last. In local Docker Compose it also holds web back until both checks pass. On Hubfly space, the order is the same, but don't count on the gate to wait for a passing check: a dependency can be marked ready within seconds of deploying. Your app's connection retry is what actually protects you, so keep it.

Step 4: Deploy the stack on Hubfly space

1. In the dashboard, click Create Project. Name it (for example shop-api), pick a region, and optionally open Advanced Options to set a monthly budget cap such as $10.
2. In the project, click Create → Compose Stack, open the YAML tab, paste the full file below, and click Import YAML.
3. Click Deploy Stack.

The file uses nginx:alpine as a stand-in web server so you can deploy it exactly as written. To use your own app, change image and point the check at your /health route and port, for example http://127.0.0.1:3000/health.

services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: shop
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: shop
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h 127.0.0.1 -U shop -d shop"]
      interval: 5s
      timeout: 3s
      retries: 5
      start_period: 20s
  cache:
    image: redis:7-alpine
    environment:
      REDIS_PASSWORD: change-me
    command: ["sh", "-c", "exec redis-server --requirepass \"$REDIS_PASSWORD\""]
    healthcheck:
      test: ["CMD-SHELL", "REDISCLI_AUTH=\"$REDIS_PASSWORD\" redis-cli ping | grep -q PONG"]
      interval: 5s
      timeout: 3s
      retries: 5
  web:
    image: nginx:alpine
    healthcheck:
      test: ["CMD-SHELL", "wget -q -O /dev/null http://127.0.0.1/ || exit 1"]
      interval: 10s
      timeout: 3s
      retries: 3
      start_period: 15s
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_healthy
volumes:
  pgdata:

Replace change-me with real passwords before you deploy anything that matters. Note that --requirepass on the command line is visible in the container's process list; for production, put the password in a Redis config file on a volume instead.

The deploy log shows the order: the volume first, then db, then cache, and web last, once both dependencies have deployed. The whole stack takes about a minute.

Step 5: Make sure each check can fail

Don't trust a check you've never seen fail. Open each container, go to the Console tab, and run its test command by hand:

# In the db container
pg_isready -h 127.0.0.1 -U shop -d shop; echo "check exit=$?"
pg_isready -h 127.0.0.1 -p 5433; echo "wrong port exit=$?"

# In the cache container
sh -c 'REDISCLI_AUTH="$REDIS_PASSWORD" redis-cli ping | grep -q PONG'; echo "check exit=$?"
redis-cli ping | grep -q PONG; echo "without password exit=$?"

# In the web container
wget -q -O /dev/null http://127.0.0.1/; echo "check exit=$?"
wget -q -O /dev/null http://127.0.0.1/missing; echo "missing page exit=$?"

You want 0 for each real check and a non-zero code for each deliberately broken one. Now you know the check can tell the difference.

The container's status badge doesn't always show the check result, so the Console is the reliable place to look.

You can change a check later on a single container: open it, go to Configuration → Health Check → Edit, update the test command, interval, timeout, start period or retries, and click Save Changes. The container restarts with the new settings.

What can go wrong

1. The check passes, but the service is broken. Classic cause: redis-cli ping without | grep -q PONG, or an HTTP check that treats any response as success. Fix: check for the exact good answer, then prove it fails by running a broken version by hand (Step 5).

2. Your password variable turns into nonsense. In a local docker compose file you must write $$REDIS_PASSWORD, because Compose replaces single $ variables with values from your laptop's environment. The Hubfly space Stack Composer passes your command to the shell exactly as written, so there you write a single $REDIS_PASSWORD. If you paste $$REDIS_PASSWORD into Hubfly, the shell reads $$ as its process ID and Redis ends up with a password like 1REDIS_PASSWORD. The symptom: your app gets WRONGPASS with the password you set. Worse, a failing check doesn't stop the stack from deploying, and the container keeps running, so nothing looks wrong at first. Fix: use $ on Hubfly, $$ locally, and check with REDISCLI_AUTH="$REDIS_PASSWORD" redis-cli ping in the Console.

3. "executable file not found" or the check always fails. The image doesn't contain curl, wget or even a shell. Fix: run which curl wget in the Console, then pick a tool the image has (Step 3). For scratch or distroless images, add a /health subcommand to your binary and use the exec form: ["CMD", "/app", "health"].

Takeaway

A health check is only useful if it can fail. Check for the real answer (PONG, a 200 from /health, pg_isready over TCP), give slow starters a start_period, use a tool the image actually contains, and run every check by hand once. Pair that with a connection retry in your app, and deploys stop being the moment your users see errors.

Related guides:

• Run a database migration before your app starts, the next step after health checks.
• Why your app shows a 502 error in Docker (and how to fix it)
• Deploy a docker-compose.yml as-is

Deploy this

Paste the Compose file from Step 4 into a new project on Hubfly space. On the free shared tier, the dashboard projects about $0.02 a month for this stack. That's the 1 GB database volume; shared runtime is free within 360 hours a month, and sleeping containers use no compute.

Go further on Hubfly space

• Send traffic only to healthy copies of your app: put a load balancer in front of two or more web containers. It uses health probes to route around a target that stops answering.
• Ship a release slowly: send 10% of traffic to a new version first with a weighted load balancer.
• Reach your database from your laptop without a public port: open a short-lived tunnel with hubfly tunnel create.

TL;DR

• What you get: which platforms take your docker-compose.yml without a rewrite, which Compose keys survive, and a monthly price for the same 3-service stack (web + Postgres + Redis) on 8 platforms.

• Who it's for: you have a Compose file that works on your laptop and you want it online without learning a new config format.

• Time: 10 minutes to read. 2 minutes to try it on Hubfly.

• Short answer: Hubfly runs the file as-is; Coolify's docs say it runs Compose natively; Railway imports it (some keys may not carry over). Render, DigitalOcean App Platform, Heroku and Koyeb want a rewrite. Cheapest always-on stack: about \(6–12/month if you run Postgres yourself, \)15–27 if you want them managed.

The problem: your Compose file works, until you try to host it

You have docker compose up working. Web, Postgres, Redis, a healthcheck, two volumes. Then you pick a host, and it wants a render.yaml, an app spec, a fly.toml or three separate services clicked together by hand.

Most "deploy Docker Compose" guides skip the two questions that matter. Will my file run unchanged? And what will the whole stack cost per month, not just the web box?

This post answers both, from each platform's docs and pricing page, plus a real Compose deploy on Hubfly with a stopwatch.

The reference stack

One small web service that waits for a healthy Postgres and a healthy Redis. Both data services have named volumes. A bind mount is included on purpose, to show what a platform does with it.

services:
  web:
    image: traefik/whoami:v1.10
    ports:
      - "80:80"
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_healthy
    volumes:
      - ./static:/srv:ro        # bind mount, on purpose
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: change-me   # use a secret in real life
      POSTGRES_DB: app
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s
      timeout: 3s
      retries: 10
    volumes:
      - pgdata:/var/lib/postgresql/data
  cache:
    image: redis:7-alpine
    command: ["redis-server", "--appendonly", "yes"]
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 10
    volumes:
      - redisdata:/data
volumes:
  pgdata:
  redisdata:

Which platforms take a Compose file?

Docs and pricing pages are linked in each row and in the price table below. "As-is" means you hand over the file, not a translation of it.

Fair warning for every row: "supports Compose" never means every key. Swarm-only deploy: blocks, host networking and bind mounts are where files usually break.

Hubfly, step by step

The Stack Composer after pasting the YAML: 3 services, 2 volumes, monthly estimate $0.02.

1. Import. Create → Compose Stack → YAML tab → paste → Import YAML. It loaded in under a second.

2. What survives. Read the generated spec (JSON tab):

• depends_on with condition: service_healthy → kept on web for both db and cache.

• Both healthcheck blocks → kept, with interval, timeout and retries.

• Named volumes → 2 volumes of 1 GB each, mounted at the right paths.

• command: on Redis → kept.

• ports: "80:80" → container port 80 exposed.

• The bind mount ./static:/srv:ro → silently dropped. No warning in the composer. If your app needs files from the host, bake them into the image or use a volume.

1. Deploy. Click Deploy Stack. "Stack deployment finished" arrives in about 79 seconds for 3 services and 2 volumes (the deploy page timer, which starts after validation, shows about 1 min 17 s).

2. Order. The log is the useful part:

• db deployed (10:54:10), then cache (10:54:26).

• "Waiting for 'db' before deploying 'web'" → "Service condition satisfied" 2 s later.

• Same for cache 3 s later. Then web deployed (10:54:48).

The deploy activity log: web waits for db and cache to become healthy.

One oddity: the composer labels stages in file order. web shows as "Stage 1" even though it deploys last. The real order followed depends_on, so trust the log, not the stage number.

1. Cost on the dashboard. The project summary projected $0.03/month, with the shared tier's auto-sleep on.

Project Settings → Billing & Monthly Budget: projected \(0.03/mo against a \)10 cap.

The composer shows $0.02, the project page $0.03. The gap is most likely the storage class: the volumes were created as Balanced (1.5× the standard rate). 2 GB × $0.00001536 × 1.5 × 730 h = $0.034, which rounds to $0.03; at the standard rate it's $0.022. Shared-tier compute shows as free here. Treat that as a dev and staging number, not a production price.

1. Cleanup. Project Settings → Danger Zone → Delete All Resources, then Delete Project. The whole run takes about 7 minutes.

What the same stack costs, platform by platform

Assumptions: always on, 730 hours a month, the smallest paid size each platform sells for web, Postgres and Redis, 1 GB of data each, no egress. Usage-based platforms are priced at 0.5 vCPU + 512 MB per service (or the nearest size), which is a ceiling, not an average.

How to read Railway's row: it bills real usage, per second. $45.30 assumes all three services use their full 0.5 vCPU and 512 MB around the clock ($20/vCPU-month × 0.5 + \(10/GB-month × 0.5 = \)15 each). An idle side project uses far less, and the $5 Hobby fee covers the first $5. An idle Railway bill depends on your app, so it isn't quoted here.

The Hubfly math, so you can check it

Published rates (pricing page): CPU \(0.004 per vCPU-hour, RAM \)0.002 per GB-hour, storage $0.00001536 per GB-hour, 730 hours a month.

• One service at 0.5 vCPU / 512 MB: 0.5 × 0.004 × 730 = $1.46 CPU, plus 0.5 × 0.002 × 730 = $0.73 RAM → $2.19.

• Three services: 3 × $2.19 = $6.57.

• Two 1 GB Balanced volumes: 2 × 0.00001536 × 1.5 × 730 = $0.034.

• Container disk, 2 GB each (the dedicated tier's minimum in the dashboard): 6 × 0.00001536 × 730 = $0.067.

• Total ≈ $6.67/month.

This row is computed from published dedicated-tier rates.

Where the competitors win (and they do)

• Managed databases. Heroku, Render and DigitalOcean run Postgres and Redis for you. If you'd rather never think about Postgres upgrades or restores, the $15–27 tier is worth it. Render's $6 Postgres includes point-in-time recovery on the Hobby workspace, per its pricing page. On Hubfly, Coolify and self-run Fly, Postgres is a container you own, and backups are your job.

• Coolify runs Compose closest to raw, including build: from your repo, and one flat-priced server. You also patch that server yourself.

• Railway's import is drag-and-drop: drop the file on the canvas and review the staged services (docs).

• Fly's 256 MB Machine is $2.19/month, and Fly lists 17 regions in its pricing selector, against Hubfly's 3. Koyeb's eco-nano ($1.61) is the cheapest always-on container in this table.

• Heroku's cheapest managed Postgres + Redis pair costs $8 together, the lowest managed pair in this table.

Where Hubfly fits: your Compose file ran unchanged, depends_on health conditions were respected, and a 3-service always-on stack is about $6.67 by the published rates. The trade-off is that you manage the database containers. Hubfly doesn't document database backups, so schedule your own pg_dump to off-site storage.

What can go wrong

1. Your bind mounts disappear. Hubfly dropped ./static:/srv:ro without a warning, and Coolify restricts them to the resource folder. Fix: COPY the files into the image, or use a named volume.

2. The app starts before the database is ready. depends_on without a condition only waits for the container to start. Fix: add a healthcheck and condition: service_healthy, as above. For migrations, gate the app on a one-shot job (see the migration job guide).

3. 502 after a "successful" deploy. Your app is listening on 127.0.0.1 inside the container. Fix: bind to 0.0.0.0 (1-line fix).

Bonus trap: a hard-coded POSTGRES_PASSWORD in Compose is fine on a laptop and bad in a repo. Use the platform's secret or encrypted env vars.

Try it yourself

1. Create a Cell project with a $10 budget cap (Advanced Options at project creation).

2. Create → Compose Stack → YAML → paste the file above (change the password) → Import YAML.

3. Check the JSON tab to see what survived. Deploy Stack and watch the activity log.

4. Delete All Resources, then Delete Project when you're done.

For competitor prices, open the linked pricing pages: prices change.

Takeaway

If you want your Compose file to run with no rewrite, your real shortlist is Coolify (your own server) or a platform with native import like Hubfly or Railway. If you want managed Postgres and Redis and don't mind translating your file, Heroku ($15) and Render ($23) are the honest picks.

Next: Canary releases with a weighted load balancer, once your stack is live and you want to ship v2 safely.

Price your own stack: open the Hubfly pricing calculator, set 3 dedicated services at 0.5 vCPU / 512 MB, and compare with the table above.

TL;DR

• What you get: a pattern for giving each customer their own wallet, projects and machine key on Hubfly, using sub-accounts. Three control-plane calls per customer, then the normal API.

• Who it's for: SaaS teams, agencies and AI-agent builders who run infrastructure for their customers.

• Time: about 10 minutes to read. Creating, suspending and revoking a tenant in the dashboard takes about 2 minutes.

The problem: one customer's bill is everyone's bill

You run a SaaS. Each customer gets a database, a worker or a preview app. On most clouds, all of that lands in one account and one bill.

Then customer 1042's import job loops all weekend. You find out from your card statement. You also can't tell which customer owes what, and one leaked key reaches every tenant.

The textbook answer is the "silo" model: a separate account per customer. On AWS this usually means AWS Organizations and an account-vending process. Most guides stop at the diagram. This post shows the actual calls on Hubfly, and the limits.

What Hubfly sub-accounts are

A sub-account is a tenant, not a team member. It has no password, no login and no invitations. Your software talks to it with a machine key (docs).

Each tenant gets:

• Its own wallet, with paid and promotional balances, in integer micro-USD (1000000 = $1.00).

• Its own projects, which are ordinary Hubfly projects: containers, Compose, volumes, domains, firewall, logs.

• Its own keys. An hfsk_ key is locked to one tenant. A parent hfpk_ key can manage all your tenants and target one with the X-HubFly-Subaccount header.

• An externalRef, unique inside your parent, so you can map customer_1042 in your database to sub_… in Hubfly.

The docs list the use cases plainly: SaaS customer infrastructure, AI agents, managed hosting, preview environments and internal developer portals.

Your app (parent hfpk_ key)
 ├── sub_A  wallet $25 ── project ── containers, volumes, domains
 ├── sub_B  wallet $10 ── project ── ...
 └── sub_C  suspended  (keys disabled)

Walkthrough: the dashboard flow

Open Profile → Sub-accounts.

1. Create. Click New sub-account, type a name such as acme-corp and an external reference such as tenant_001, and click Create sub-account. It shows as Active with a sub_… ID within seconds.

2. Inspect. Manage opens a panel with the wallet balance ($0.00), active keys, status, a Fund wallet box ("Move paid balance from the parent account"), Machine credentials and Suspend account.

1. Key (the surprise). New key has no form. The dashboard immediately creates a key called Master key and shows the hfsk_ secret once, with "HubFly stores only a hash of this key and cannot recover it later." If you don't need it, close the dialog and click Revoke. The banner says "API key revoked." and active keys go back to 0. Note that Revoke also has no confirmation step.

1. Suspend. Suspend account works in one click, again with no confirmation. Status changes to Suspended, New key greys out, and the button becomes Resume account.

Everything above costs $0.00. Funding the wallet and closing a tenant happen through the API below; the dashboard has no Close button, so a tenant you stop using stays suspended until you close it by API.

The production flow: 4 calls to onboard, 1 to close

The dashboard is fine for a look around. For real customers, provision from your backend with a parent platform key. These come from the Sub-account API guide; all paths are under https://api.hubfly.space/api/v1.

1. Create the tenant. Use an idempotency key, so a retry returns the same tenant instead of a duplicate.

curl -X POST https://api.hubfly.space/api/v1/subaccounts/create \
  -H "Authorization: Bearer $HUBFLY_PLATFORM_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: tenant-customer-1042-v1" \
  -d '{"name":"Customer 1042","externalRef":"customer_1042"}'

2. Fund its wallet. This moves paid balance from your parent wallet. Promotional credit can't be transferred.

curl -X POST https://api.hubfly.space/api/v1/subaccounts/$SUBACCOUNT_ID/wallet/transfers \
  -H "Authorization: Bearer $HUBFLY_PLATFORM_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: funding-customer-1042-2026-10" \
  -d '{"amountMicroUsd":"25000000","idempotencyKey":"funding-customer-1042-2026-10"}'

3. Mint a tenant key and write it straight to your secret manager. It's shown once.

curl -X POST https://api.hubfly.space/api/v1/subaccounts/$SUBACCOUNT_ID/api-keys/create \
  -H "Authorization: Bearer $HUBFLY_PLATFORM_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"production workload"}'

4. Use the normal endpoints. There are no special tenant URLs. With the tenant key, GET /projects lists only that tenant's projects. With your platform key, add -H "X-HubFly-Subaccount: $SUBACCOUNT_ID". The TypeScript and Go SDKs and the CLI (--subaccount sub_… or HUBFLY_SUBACCOUNT) support the same pattern.

5. Close when the customer leaves. Stop and remove the tenant's projects, settle any negative balance, then call POST /subaccounts/$SUBACCOUNT_ID/close. Eligible paid balance returns to your parent wallet; promotional balance expires; keys are revoked.

Isolation rules: an hfsk_ key sent with a different tenant header gets 403 SUBACCOUNT_SCOPE, and a platform key can't target a tenant outside its parent.

Limits and pricing (honest version)

Limits:

• 25 active sub-accounts per parent and 10 active keys per parent or tenant, by default.

• One level deep: a tenant can't create tenants. You can't move a tenant to another parent.

• No GPU, no GitHub OAuth repo discovery, no team members or invitations, no payment methods inside a tenant.

• No automatic top-up for tenant wallets in the first release.

• Suspending doesn't stop running resources. The docs say to stop billable resources before you suspend.

• Closing needs no active projects and no negative balance. Force close isn't available yet.

Pricing: sub-accounts have no listed fee. A tenant pays normal Hubfly rates from its own wallet: \(0.004 per vCPU-hour, \)0.002 per GB-hour of RAM, $0.00001536 per GB-hour of Standard storage.

Whether each tenant gets its own 360 free hours isn't documented, so don't price your plans on it. Per the pricing page, sleeping containers pause compute billing; volumes are still billed.

What can go wrong

1. You mint keys by accident. One click on New key creates a key named Master key. Create keys from your backend, name them per workload, and revoke old ones after rotation.

2. You suspend a tenant and it keeps billing. Suspension disables credentials and changes, not running containers. Stop the tenant's workloads first, then suspend.

3. A customer passes someone else's tenant ID. Never accept a subaccountId from the client. Resolve it from your own customer record, and alert on 403 SUBACCOUNT_SCOPE.

4. 409 API_KEY_LIMIT_REACHED. A tenant holds 10 active keys by default. Revoke unused keys before creating another.

Bonus: an ambiguous funding failure. Don't retry with a new idempotency key until you've read the wallet; you could fund twice.

Who this is NOT for

• Your own team. For colleagues, use an organization with roles. Sub-accounts have no logins.

• GPU workloads per customer. Not supported in tenants today.

• More than 25 customers, today, with no plan. That's the default cap. Talk to us first if you need more.

• Customers who must hold their own bill. Tenants have no payment methods; you fund them from your paid balance.

Takeaway

If you sell software that runs on infrastructure, sub-accounts give you the silo model without account vending: one wallet, one project namespace and one revocable key per customer. Provision from your backend with idempotency keys, keep keys out of the dashboard, and stop workloads before you suspend.

Read next: Let your coding agent deploy to Hubfly safely (give each agent its own tenant), Gate your app on a Postgres migration job and 502 Bad Gateway in Docker? Bind to 0.0.0.0.

Building a platform on Hubfly? Talk to sales about tenant limits, or start free with 360 hours included and create your first sub-account in Profile → Sub-accounts.

TL;DR

• What you get: a canary release that sends exactly 1 in 10 requests to a new version, a 7-line script that proves the split, and a rollback that takes effect in under a second.

• Who it's for: anyone running plain containers (no Kubernetes, no service mesh) who wants to ship v2 to a slice of users first.

• Time: about 15 minutes.

You've got v2 ready. The tests pass. Your stomach still says "not for everyone at once."

A canary release fixes that: v2 gets a small slice of real traffic, you watch it, then you turn the dial up or pull it out. Setting a 90/10 split takes a minute. Checking that you actually got one is the part people skip, and a 90/10 setting can quietly give you something else.

How a weighted canary works

A load balancer sits in front of two backends. Each backend gets a weight. With weights 9 and 1, a weighted round robin sends 9 requests to v1, then 1 to v2, and repeats.

           ┌──────────────────────┐
Internet → │  load balancer (WRR) │ ──9──→ app-v1 (stable)
           │  canary-router       │ ──1──→ app-v2 (canary)
           └──────────────────────┘

Three things decide whether this works in practice:

1. The strategy must actually read the weights. Some strategies ignore them.

2. Sticky strategies change who sees v2. IP hashing pins each client to one backend, so a 10% canary means "10% of clients", and you may never be one of them.

3. Rollback must be one action. If pulling v2 out takes a redeploy, it isn't a canary, it's a hope.

Build it on Hubfly, then check all three.

Step 1: deploy v1 and v2 side by side

Here, both versions are hashicorp/http-echo, a tiny server that replies with a fixed string. That makes counting trivial: every response says v1 or v2. In real life, these are your two image tags.

services:
  app-v1:
    image: hashicorp/http-echo:1.0
    command: ["-listen=:5678", "-text=v1"]
  app-v2:
    image: hashicorp/http-echo:1.0
    command: ["-listen=:5678", "-text=v2"]

In the Hubfly dashboard: open your project, click Create → Compose Stack, open the YAML tab, paste the file, click Import YAML, then Deploy Stack. Neither service publishes a port. The load balancer will be the only way in.

The stack is up in about 33 seconds.

Step 2: create the load balancer

Click Create → Create Load Balancer. The editor has three columns: ingress domains on the left, the balancer in the middle, backend targets on the right.

1. Balancer name: canary-router.

2. Backend targets → Add Target Container: pick app-v1, set Port to 5678, Weight to 9, click Add Target. Repeat for app-v2 with weight 1.

3. Ingress domains → Add Domain → Hubfly Free → Attach Free Domain. You get an HTTPS subdomain like canary-router-xx-xxx.eu1.hubfly.app.

4. Strategy: choose Weighted Round Robin. Not "Round Robin". This is the step the rest of this post is about.

5. Click Deploy Load Balancer.

Watch the port: the target form defaults to 3000. This app listens on 5678, so leaving the default points the balancer at a closed port.

Hubfly's load balancer docs describe three strategies (round_robin, least_conn, ip_hash) and a canary recipe with weight: 9 and weight: 1. The dashboard offers eight. Only the weighted strategies apply your weights.

Step 3: prove the split (don't trust the percentages)

Open your load balancer's domain in a browser tab. It shows v1 or v2. Then open the browser console (F12 → Console) on that tab and paste:

const counts = {};
for (let i = 0; i < 200; i++) {
  const r = await fetch('/?n=' + i + '&t=' + Date.now(), { cache: 'no-store' });
  const body = (await r.text()).trim();
  counts[r.status + ' ' + body] = (counts[r.status + ' ' + body] || 0) + 1;
}
console.table(counts);

It sends 200 sequential requests from the same origin, skips the cache, and counts each status-plus-body pair. A run takes about 80 seconds (median 402 ms per request).

Here is what you get with the same two containers and the same 9/1 weights, changing only the strategy:

Every response was a clean v1 or v2 reply, with no errors.

What the table says:

• Round Robin ignores your weights. The target cards still show "90%" and "10%", which is what makes it dangerous. A repeat run settles into strict alternation: v1, v2, v1, v2. Your "10% canary" is a coin flip. (A first run can start with 15 v1 responses, then a long v2 streak, then the same alternation; that run gave v2 61%.)

• Weighted Round Robin is exact. v2 answered request 1, 11, 21 and so on. Precisely 20 of 200. No randomness, so you don't need thousands of requests to trust it.

• Target count also works. Three v1 containers and one v2 under plain Round Robin gave exactly 25%. That's the fallback if you're on a balancer without weights, but it costs you extra containers.

• IP hash pins you. With Weighted IP Hash, all 40 requests from a single browser go to v1. That's what you want for sessions. It's terrible for checking your canary from your own laptop.

Step 4: watch v2, then promote or roll back

While v2 takes its 10%, watch two numbers per version: error rate and latency. On Hubfly, each container has its own Logs and Metrics tabs, so you can check app-v1 and app-v2 separately. One Traefik canary guide rolls back when the canary's 5xx rate passes 5%, and alerts when p95 latency stays above 2 seconds for 5 minutes. Pick numbers that match your app.

Promote: raise app-v2's weight in steps (for example 1 → 3 → 9 against v1's 9), checking each step with the script. When v2 carries everything, remove app-v1 from the targets. The balancer details panel edits weights live, and every step uses the same control. The balancer also health-checks targets with lightweight requests to paths like /health and drops a failing one from rotation, as described in the docs. Give v2 a real health endpoint so that check means something.

Roll back: open the balancer, click the trash icon on the app-v2 target. With a request loop running, the last v2 response comes back about 0.66 s after the click, and none of the 108 requests in that loop fail.

What can go wrong

1. "I set 90/10 and v2 gets half the traffic." Your strategy is plain Round Robin. It ignores weights, even though the UI shows percentages. Pick the Weighted version of whichever strategy you use, then rerun the script.

2. "I can't reproduce the bug users report on v2." You're on an IP-hash strategy, and your IP hashes to v1. Weights then decide which clients land on v2, not which requests. Test v2 directly before adding it to the balancer, or temporarily use Weighted Round Robin while you test.

3. "v2 never answers after I add it." Check the target port. The form defaults to 3000. If your container listens elsewhere (here: 5678), the balancer is knocking on a closed door. Also check that v2 is running before you add it.

Two smaller gotchas from the dashboard: the + button next to a weight steps by 5 (1 → 6 → 11), and scrolling the mouse wheel over a weight slider changes it. Re-read the weights before you close the panel.

The cost

Four shared-tier containers plus the balancer project to $0.00/month in the dashboard. The shared tier counts against the free 360 compute hours a month.

For a production-sized canary, say both versions as dedicated containers with 1 vCPU, 0.5 GB RAM and 5 GB disk, each one costs about $3.71/month always on:

• CPU: 1 × \(0.004 × 730 h = \)2.92

• RAM: 0.5 × \(0.002 × 730 h = \)0.73

• Disk: 5 × $0.00001536 × 730 h ≈ $0.06

The canary only exists during the rollout. Running v2 next to v1 for a 24-hour canary adds about $0.12.

Takeaway

Setting a weight is not the same as getting a split. Pick a weighted strategy, then count. Two hundred requests and one table tell you more than the dashboard's percentages do.

Read next:

• 502 Bad Gateway in Docker? Bind to 0.0.0.0, not 127.0.0.1: if your new target returns 502s, start here.

• Gate your app on a Postgres migration job: schema changes are the main reason a rollback isn't safe. Make them backward-compatible before the canary.

• Let your coding agent deploy to Hubfly, not delete your data.

Finished with the canary? Delete the load balancer separately. Danger Zone → Delete All Resources removes the containers but leaves the balancer behind.

Deploy this

Paste the Compose file above into a new Hubfly project, add a load balancer with Weighted Round Robin and weights 9 and 1, and run the script. The free tier needs no card, and this setup projects to $0.00/month. Start on Hubfly.

TL;DR

• What you get: a 30-second check that tells you if a 502 is a bind-address bug, the one-line fix for 9 common servers, and 3 traps to avoid.

• Who it's for: anyone whose container logs say "listening" while the browser says 502.

• Time: 5 minutes to diagnose, 1 line to fix.

Your container is running. The logs say the server started. The dashboard says the port is open. And every request through the proxy gets 502 Bad Gateway.

Often, nothing is "down". Your app is listening on 127.0.0.1, and inside a container that address means "this container only". The proxy knocks on the container's network interface, nobody answers, and you get a 502.

Here's how to prove it in 30 seconds, fix it in one line, and avoid three easy traps.

Why 127.0.0.1 breaks inside a container

Every container has its own network namespace. It has its own loopback (lo, 127.0.0.1) and its own interface (eth0, a private IP).

Internet ──HTTPS──► reverse proxy ──► 10.240.82.2:8000 (eth0) ──✗──  app on 127.0.0.1:8000
                                                                     (only lo can reach it)

A server bound to 127.0.0.1:8000 accepts connections that arrive on lo only. The proxy's request arrives on eth0, so the kernel refuses it. The proxy turns "connection refused" into a 502.

Binding to 0.0.0.0 means "every interface in this container", which includes eth0. It does not open anything on the host or the internet by itself: the container is still only reachable through the routes you set up.

Reproduce it: one broken container

Deploy this on Hubfly with the Compose import. The image is stock python:3.12-alpine, so there's no build step.

services:
  broken:
    image: python:3.12-alpine
    command: ["python", "-m", "http.server", "8000", "--bind", "127.0.0.1"]
    expose: ["8000"]
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://127.0.0.1:8000/"]
      interval: 10s
      retries: 3

The stack deployed in 33 seconds:

Then add a public HTTPS domain on port 8000 (Network → Add Domain → Auto Endpoint) and open it:

Note the page's advice: "This is usually temporary, try again in a few seconds." For a bind bug, retrying forever won't help. It's a configuration error, not a blip.

Step 1: Prove it's the bind address (30 seconds)

Open a shell in the container. On Hubfly that's the container's Console tab. Elsewhere, use docker exec -it <container> sh.

Run these four commands:

netstat -tln        # or: ss -ltn
IP=$(ip -4 -o addr show eth0 | awk '{print $4}' | cut -d/ -f1); echo $IP
wget -qO- http://127.0.0.1:8000/ | head -c 40; echo
wget -qO- http://$IP:8000/ | head -c 40; echo

Here is the output from the broken container:

/ # netstat -tln
Proto Recv-Q Send-Q Local Address    Foreign Address   State
tcp        0      0 127.0.0.1:8000   0.0.0.0:*         LISTEN
/ # IP=$(ip -4 -o addr show eth0 | awk '{print $4}' | cut -d/ -f1); echo $IP
10.240.82.2
/ # wget -qO- http://127.0.0.1:8000/ | head -c 40; echo
<!DOCTYPE HTML>
<html lang="en">
<head>
/ # wget -qO- http://$IP:8000/ | head -c 40; echo
wget: can't connect to remote host (10.240.82.2): Connection refused

How to read it:

If loopback answers and the eth0 IP is refused, you've found it. Use $IP from ip, not hostname -i: in this container hostname -i prints 127.0.1.1, which is another loopback address and proves nothing.

Step 2: Fix it in one line

Change the bind address to 0.0.0.0. Here that is one argument:

command: ["python", "-m", "http.server", "8000", "--bind", "0.0.0.0", "--directory", "/srv"]

On Hubfly, edit Configuration → Process Settings → Command (one argument per line) and save. The new command takes effect, and the same public URL returns 200 within about 20 seconds. netstat now shows:

tcp        0      0 0.0.0.0:8000     0.0.0.0:*         LISTEN

Why --directory /srv? See trap 3 below. It's the part most people miss.

The one-line fix for 9 common servers

Most of these default to loopback because they're built for your laptop, where loopback is the safe choice. In a container, it's the wrong one.

Better still, read the host and port from environment variables (HOST=0.0.0.0, PORT=8000) so the same image runs on your laptop and in production.

What can go wrong

1. The dashboard says the port is open, and it's still a 502.

While the broken container is running, Hubfly's Add Domain dialog lists 8000 under "Suggested ports" as "Open now". The scan counts a loopback-only listener as open. "Open" means something listens on 8000; it doesn't mean the proxy can reach it. Trust netstat's Local Address column instead.

2. Your healthcheck can't see this bug.

A healthcheck that runs wget http://127.0.0.1:8000/ inside the container runs on loopback, so a loopback-only server passes it. Run that exact command in the broken container and you get HTML back. (On Hubfly the health badge may show "Unknown" rather than green, but the check itself passes.)

In-container checks can't catch this bug. Check from outside too: open the public URL, or check from another container: set an env var TARGET={{service:broken.host}} on it, then run wget -qO- http://$TARGET:8000/ in its Console.

3. The fix can publish your whole filesystem.

Changing only 127.0.0.1 to 0.0.0.0 is not enough. The public URL then shows a directory listing of the container's /: bin/, etc/, root/ and more. python -m http.server serves the working directory, which is /. Adding --directory /srv fixes it.

The lesson is bigger than Python: once you bind to 0.0.0.0, whatever that port serves is public through your domain. Look at the page before you share the link.

Two more causes of 502 that look the same from the browser:

• Wrong port: the domain points at 80, the app listens on 8000. Match the domain's container port to netstat.

• The app crashed: netstat shows nothing listening at all. Check the logs for a stack trace, not the bind address.

Takeaway

A 502 from a container that's "running" is usually a bind address, not an outage. Run netstat -tln. If you see 127.0.0.1, change it to 0.0.0.0, then check what that port now serves to the world.

Read next: Gate your app on a Postgres migration job with depends_on: service_completed_successfully. It covers the other classic "it's running but broken" Compose bug. More guides are on the Hubfly blog.

Deploy this

Want to see the bug and the fix side by side? Paste the Compose file above into Create → Compose Stack → YAML in the Hubfly dashboard, add a domain on port 8000, and watch the 502. Then replace the command with the fixed one from Step 2, including --directory /srv. Changing only the bind address publishes the container's whole filesystem. The shared tier (0.3 vCPU, 256 MB) is enough, and it falls inside the free 360 compute hours a month. See pricing and the CLI docs if you'd rather do it from a terminal.

TL;DR

• What you get: a coding agent that can inspect, plan and deploy your app on Hubfly, but has to ask before it deploys, and is blocked from the usual commands that delete volumes or read your token (a fence, not a vault: see the limits below).

• Who it's for: solo devs and small teams already using Claude Code, Codex or Cursor who are tired of copy-pasting deploy commands.

• Time: about 15 minutes. Cost: the skill is free; you pay only for what gets deployed (≈ $3.71/month for one always-on 1 vCPU / 512 MB container, math below).

The problem

Your agent wrote the feature, ran the tests and opened the PR. Then it stops and hands you a list of deploy commands to paste. So you give it shell access to your cloud CLI, and now the same agent that once deleted your node_modules "to clean up" can also run stack down --volumes.

The question isn't "should the agent deploy?" It's "which commands can it run alone, which need a yes, and which should never run at all?"

What Hubfly gives the agent

Hubfly publishes a CLI skill for coding agents at hubfly.space/ai. It's a plain SKILL.md in the portable Agent Skills format, plus three reference files (API, networking, diagnostics). Hubfly says it contains no credentials or executable scripts.

The skill teaches the agent a 5-step loop:

1. Inspect: read the app, the hubfly.build.json manifest, ports, volumes and env var names.

2. Reconcile: compare local settings with the container already running in the cloud.

3. Plan: review the server-side plan and any destructive operations before rolling out.

4. Authorize: ask you when a new cost, a new target or a destructive action needs a decision.

5. Follow: track the deployment session and report the real final state or the exact phase that failed.

Three rules in the skill do most of the safety work:

• --yes only suppresses a CLI prompt. It is not permission. Your request decides what the agent may do.

• hubfly stack down --volumes deletes durable data and needs a separate confirmation that names the volumes.

• Never print secret values or tokens; avoid printenv. A local build or upload is not "deployed" until the Dashboard says so.

That's the agent's conscience. Now give it a fence, because a conscience is just a prompt.

Walkthrough: Claude Code + Hubfly in 4 steps

1. Install the CLI and log in yourself

curl -fsSL https://raw.githubusercontent.com/hubfly-space/hubfly-cli/main/install.sh | bash
hubfly version
hubfly login      # get a token at dashboard.hubfly.space/cli/auth and paste it
hubfly whoami

Log in yourself, in your own terminal. The token lands in ~/.hubfly/config.json. Don't paste it into the chat and don't commit it.

2. Add the skill to your repo

mkdir -p .claude/skills/hubfly-cli/references
curl -fsSL https://hubfly.space/skills/hubfly-cli/SKILL.md \
  -o .claude/skills/hubfly-cli/SKILL.md
for ref in api networking diagnostics; do
  curl -fsSL https://hubfly.space/skills/hubfly-cli/references/$ref.md \
    -o .claude/skills/hubfly-cli/references/$ref.md
done

For Codex use .codex/skills/hubfly-cli/, for Cursor .cursor/skills/hubfly-cli/, or the portable .agents/skills/hubfly-cli/. Read the file before you commit it. It's short, and you should know what your agent was told.

The skill also asks agents to re-fetch the live SKILL.md for each task and to add a small hubfly block to CLAUDE.md or AGENTS.md. A safer habit is to commit your reviewed copy and re-pull it when Hubfly updates it, so a change to the live file never reaches your agent unread.

3. Write the fence: .claude/settings.json

{
  "permissions": {
    "allow": [
      "Bash(hubfly whoami)",
      "Bash(hubfly version)",
      "Bash(hubfly stack status *)",
      "Bash(hubfly stack plan *)",
      "Bash(hubfly build validate *)",
      "Bash(hubfly build explain *)",
      "Bash(hubfly logs *)",
      "Bash(hubfly stack logs *)"
    ],
    "ask": [
      "Bash(hubfly deploy *)",
      "Bash(hubfly stack up *)",
      "Bash(hubfly exec *)",
      "Bash(hubfly ssh *)",
      "Bash(hubfly tunnel *)",
      "Bash(hubfly stack exec *)",
      "Bash(hubfly stack ssh *)",
      "Bash(hubfly container *)",
      "Bash(hubfly compose *)"
    ],
    "deny": [
      "Bash(hubfly stack down *)",
      "Bash(hubfly stack down --volumes *)",
      "Bash(hubfly compose down *)",
      "Bash(hubfly logout *)",
      "Bash(hubfly login *)",
      "Bash(printenv *)",
      "Read(~/.hubfly/**)"
    ]
  }
}

The skill also lists a hubfly compose alias and container subcommands, so fence those too. login is denied: you log in, never the agent. This file is Claude Code's format. Codex and Cursor have their own approval settings; the same allow/ask/deny split applies.

How Claude Code reads this, per its permissions docs:

• Rules are checked deny, then ask, then allow. The first match wins, and specificity doesn't change the order.

• So hubfly deploy plan will also prompt, because it matches the ask rule first. That's on purpose: the skill warns deploy plan isn't guaranteed read-only (it can bind or create a remote project), and it isn't in the CLI docs yet. Read it before you approve.

• Bash(hubfly logs *) also matches the bare hubfly logs. The space before * matters.

• Read(~/.hubfly/**) keeps the token file out of the agent's context, and also blocks edits to it.

• Allow rules in a committed .claude/settings.json only apply after you accept the workspace trust prompt. Deny and ask rules apply right away.

stack down is denied, not asked. If a stack needs tearing down, that's one command worth typing yourself.

4. Ask for a deploy

Start Claude Code in the repo and try one of the prompts Hubfly suggests:

Deploy my web app with HTTPS and keep Postgres private with tunnel access.

What you should see, if the skill is doing its job:

• the allow-listed commands (whoami, stack plan, build explain) run without prompts once you've trusted the workspace;

• a plan that lists services, ports and volumes, with the database not exposed publicly;

• a permission prompt on hubfly stack up or hubfly deploy, which is your moment to read the plan;

• a final report that names the Dashboard's terminal state, not just "image uploaded".

For a Compose app, the reviewed plan is hubfly stack plan --json. If you want to see how a multi-service deploy gates on a migration job, the migration-job tutorial walks through it end to end.

Add a money fence on the Hubfly side

Permission rules match the command text the agent writes. Claude Code's own docs say a deny rule isn't a security boundary: sh -c 'hubfly stack down ...' or a full path can slip past it. So put a second fence where the agent can't edit it:

• Project budget limit. When you create a project, Advanced options offer a monthly budget limit with presets of $10, $50 and $100. Pick the smallest one that fits. Hubfly's pricing page says a budget cap stops workloads when it's hit (the billing docs don't cover it yet). How quickly it stops them isn't documented, so treat it as a ceiling, not a real-time alarm.

• One project for agent work. Point the agent at it with --project and say so in your prompt. The skill treats a new target as something to ask about.

• Audit log. Hubfly logs redeploys, env var changes, member role updates and API key generations, with UTC timestamp, IP, actor email and session, the resource changed, and a before/after diff. Check it after the agent's first few runs.

What can go wrong

1. The agent adds --yes and you assume it skipped your approval. It didn't. --yes skips the CLI's prompt. Claude Code's ask rule still fires on hubfly deploy *. If you never see a prompt, check that you're not in bypass-permissions mode and that /permissions still shows the ask rule. An allow rule can't override an ask rule.

2. Secrets end up in the transcript. An agent debugging env vars loves printenv. The deny rule and the skill both block the obvious form, but hubfly exec web -- env is another. That's why exec is in ask: read the command before you approve it.

3. The agent "succeeds" at the wrong layer. A local build or upload isn't a deploy. If the report doesn't mention the Dashboard's final state or a health check, ask for hubfly stack status before you trust it.

Limits and pricing, honestly

What it costs. The skill and CLI are free. You pay Hubfly's normal rates for what the agent deploys: \(0.004 per vCPU-hour, \)0.002 per GB-hour of RAM, $0.00001536 per GB-hour of storage. One always-on dedicated container (1 vCPU, 512 MB, 5 GB) over 730 hours:

A shared-tier container auto-sleeps when idle and is free within the 360 compute hours included each month, which is plenty for preview deploys.

What it doesn't do (yet):

• The CLI docs don't describe token scopes. A personal access token acts as you, so the fences above matter.

• There's no documented approval queue on Hubfly's side. The approval step lives in your agent's permission settings.

• Backups, snapshots and an SLA aren't documented yet. Keep your own database backups before letting anything automated near production.

Who this is NOT for

• Teams that need per-project, least-privilege API tokens today. Wait for documented scopes, or keep the agent on a non-production project.

• Production databases with no backup. Fix that first. No permissions file replaces a restore you've tested.

• Fully unattended CI deploys. This setup assumes a human answers the ask prompt. For CI, use HUBFLY_TOKEN as a secret and a normal pipeline.

Takeaway

Let the agent read everything, make it ask before it deploys, and block the commands that delete. The Hubfly skill gives it the right habits. .claude/settings.json gives you the prompt. A project budget limit gives you a ceiling the agent can't argue with.

Read next: Gate your app on a Postgres migration job · Deploy Odoo with PostgreSQL and persistent storage · Hubfly CLI docs

Start free, 360 hours included. Install the skill, point your agent at a fresh project with a $10 budget limit, and let it ship your next preview. Create your Hubfly account →

You have one small app and a Postgres database, and four pricing pages that use four different units. Here is what that setup costs on each platform, with the math shown.

TL;DR

• What you get: the monthly list price of the same small setup (one web app with 512 MB of RAM, one Postgres database with 1 GB of disk, running 24/7) on four platforms, with every line of math.

• Who it's for: solo developers and small teams picking a home for a side project or a first production app.

• Time needed: 8 minutes to read, 5 minutes to redo the math for your own app.

• Short answer: Heroku $12.00, Render $13.00, Railway about $7.26 for a mostly idle app (more if it's busy), Hubfly about $7.42. The cheapest is not the same as the best fit; the section "Where each one wins" is the part to read.

The problem: four pricing models that don't line up

You have a small app and a Postgres database. You want to know what it will cost before you move.

Then you open four pricing pages. One sells fixed-size dynos. One sells instance plans plus a workspace fee.

One bills per second of CPU and RAM you actually use. One bills per hour of CPU and RAM you allocate. So "which is cheaper?" turns into a spreadsheet afternoon.

This post is that spreadsheet, done once, with links. Prices change, so every price links to the vendor's own pricing page.

The reference app

To compare like with like, here is one setup priced everywhere:

• Web app: one instance, about 512 MB of RAM, always on (730 hours a month).

• Database: Postgres, 1 GB of data, always on.

• Traffic: small. Bandwidth stays out of the totals and is covered separately below.

• No free tiers in the totals. Free tiers sleep or expire, so they get their own section.

A month is 730 hours on every platform.

The comparison table

Prices come from each vendor's official pricing page, linked in the platform sections below.

The math, platform by platform

Heroku: $12.00

• Basic dyno: $7 a month, 0.5 GB RAM (pricing).

• Heroku Postgres Essential-0: $5 a month, 1 GB disk (pricing).

• \(7 + \)5 = $12.00.

Heroku "prorates all costs to the second". The listed price is the maximum you pay for a dyno that runs all month (usage and billing).

Billing is on wall-clock time, not CPU time, so an idle dyno costs the same as a busy one.

Cheaper Heroku option: Eco dynos cost $5 for a pool of 1,000 dyno hours a month, shared by all Eco dynos in your account. An Eco web dyno sleeps after 30 minutes without web traffic (Eco dyno hours). Eco plus Essential-0 is $10, if you can live with the sleep.

Render: $13.00

• Smallest paid instance: $7 a month, 512 MB RAM, listed as under 1 CPU (pricing).

• Smallest paid Postgres: $6 a month, 256 MB RAM, under 1 CPU. The page lists "1 GB SSD storage included" and "Expandable storage ($0.30/GB)" (pricing).

• Hobby workspace: $0 a month plus compute (pricing).

• \(7 + \)6 + $0 = $13.00.

If your data grows to 10 GB, add 9 GB × \(0.30 = \)2.70.

If you need team features, the Pro workspace is $25 a month on top of compute (pricing). That one line changes the answer for teams, so check which workspace plan you need.

Railway: about $7.26 light, about $20.45 busier

Railway bills resources per second (pricing):

• vCPU: $0.00000772 per vCPU-second

• Memory: $0.00000386 per GB-second

• Volume: $0.00000006 per GB-second

Converted to a 730-hour month (× 3,600 × 730):

• vCPU: $0.00000772 × 2,628,000 = $20.29 per vCPU-month

• Memory: $0.00000386 × 2,628,000 = $10.14 per GB-month

• Volume: $0.00000006 × 2,628,000 = $0.16 per GB-month

The Hobby plan is a $5 minimum usage commitment that covers your first $5 of usage. A $3 usage month bills $5; an $8 month bills $8 (understanding your bill).

Because you pay for what the app and database actually use, here are two cases:

• Light (app and database together average 0.1 vCPU and 0.5 GB RAM): 0.1 × \(20.29 + 0.5 × \)10.14 + 1 × \(0.16 = \)2.03 + \(5.07 + \)0.16 = $7.26.

• Busier (together 0.5 vCPU and 1 GB RAM): 0.5 × \(20.29 + 1 × \)10.14 + \(0.16 = \)10.14 + \(10.14 + \)0.16 = $20.45.

Your real bill sits wherever your usage graph sits. That is Railway's main strength and its main uncertainty.

Hubfly: about $7.42

Hubfly bills allocated CPU and RAM by the hour (pricing):

• CPU: $0.004 per vCPU-hour

• RAM: $0.002 per GB-hour

• Storage: \(0.00001536 per GB-hour (about \)0.011 per GB-month); the Balanced tier is 1.5× and High Performance is 2×

The dedicated tier defaults to 1 vCPU, 512 MB RAM and 5 GB of disk, always on (docs). Per container:

• CPU: 1 × \(0.004 × 730 = \)2.92

• RAM: 0.5 × \(0.002 × 730 = \)0.73

• Disk: 5 × \(0.00001536 × 730 = \)0.06

• Per container ≈ $3.71

App plus Postgres container: 2 × $3.706 ≈ $7.41. If you add a separate 1 GB volume for the data, add about $0.01 at the base rate. Total ≈ $7.42.

You can size containers differently from the tier default. Hubfly's pricing page shows a 0.5 vCPU, 1 GB, 10 GB disk container running 24/7 at about $3.03 a month (pricing).

The math: 0.5 × \(0.004 × 730 = \)1.46, plus 1 × \(0.002 × 730 = \)1.46, plus 10 × \(0.011 = \)0.11.

Where each one wins

A cheaper total doesn't settle it. Here is where each platform is the better pick, based on what their own pages say.

Heroku wins on a managed Postgres product and an add-on marketplace. Heroku Postgres is sold as its own product, and the Elements Marketplace lists add-ons (pricing). If your team already runs on Heroku, staying costs you no migration work.

Render wins on managed Postgres features at a low price. Render's Hobby workspace lists "Database PITR" (point-in-time recovery, 3-day window; 7 days on Pro), custom domains, and firewall and DDoS mitigation at $0 plus compute (pricing). Point-in-time recovery on a $6 database is a real feature. Hubfly does not document backups or snapshots yet.

Railway wins when your app is idle most of the time. Usage billing means a quiet app pays for the little it uses. Railway's Serverless setting can also put a service to sleep after 5 to 10 minutes without outbound traffic (app sleeping).

Hubfly wins on raw allocated CPU per dollar and on fixed, predictable math. One full vCPU with 512 MB for about $3.71 a month is cheap. The bill is a straight line: allocation × rate × hours, with no workspace or seat fee. Projects can have a monthly budget cap that stops workloads when it is reached (docs).

Where Hubfly loses today, in plain words:

• Postgres on Hubfly is a container from a template, with a volume. Backups and snapshots aren't documented, so plan your own pg_dump schedule.

• Fewer regions: Europe (two) and the central US at the time of writing.

• A smaller ecosystem than Heroku's add-ons.

• Allocation billing means an idle 1 vCPU container still costs $2.92 of CPU a month. On Railway, an idle app costs less.

Free tiers: what you actually get

None of these are in the totals, because each one sleeps, expires or caps out.

Note the Render database one. A free database that's deleted after 44 days is fine for a quick experiment and dangerous for anything else.

Bandwidth: the line item that breaks totals

• Render: Hobby includes 5 GB a month, then $0.15 per GB (pricing).

• Railway: $0.05 per GB of egress (pricing).

• Heroku and Hubfly: the pages linked here list no per-GB egress rate. Check before you plan heavy traffic.

At 50 GB a month, Render adds 45 × \(0.15 = \)6.75 and Railway adds 50 × \(0.05 = \)2.50. For a media-heavy app, bandwidth can outweigh compute.

What can go wrong

1. You compare allocation with usage. Railway's light case assumes a quiet app. If your app holds 1 GB of RAM all month, Railway's memory line alone is $10.14. Fix: check your current app's real RAM graph before you trust any total.

2. The database outgrows the plan. Heroku Essential-0 has 1 GB of disk; Render's $6 plan includes 1 GB, then $0.30 per GB. Fix: price the database at the size it will be in six months, not today.

3. The workspace or team fee appears later. Render Pro is $25 a month; Railway Pro is a $20 minimum. Fix: add the plan you'll need once a second person joins.

Takeaway

For one small app with Postgres running all month, list prices land between about $7 and $13, or about $20 on Railway if the app is busy. Hubfly and a quiet Railway app are cheapest. Heroku and Render cost a few dollars more and include a managed Postgres product. Only Render's includes point-in-time recovery at this price.

Pick by the line you can't live without:

• Managed Postgres with point-in-time recovery at this price: Render (Heroku offers rollback from its Standard-0 Postgres tier up).

• Pay only for what a mostly idle app uses: Railway.

• The lowest fixed price for always-on CPU, with a budget cap: Hubfly.

Read next: Gate your app on a Postgres migration job with depends_on: service_completed_successfully, the Hubfly docs on Compose stacks, and the Hubfly pricing page for the full rate card.

Price your own app

Your Hubfly bill is one formula: (vCPU × \(0.004 + GB RAM × \)0.002) × 730 + disk GB × \(0.011. For this post's app that is (1 × 0.004 + 0.5 × 0.002) × 730 + 5 × 0.011 ≈ \)3.71 per container.

Plug in your own numbers, check them against the line items on the Hubfly pricing page, and start on the free tier (no card needed).

TL;DR

• What you get: a 3-service Compose file (Postgres, a one-shot migration job, an API) where the API cannot start until the migration exits 0.

• Who it's for: anyone whose app has ever booted against a database with a missing table.

• Time: about 20 minutes. The rollout itself takes about a minute: 59 seconds from click to "Stack deployment finished".

Your app started before your schema did

You push a release. The API boots, runs its first query, and gets relation "todos" does not exist. The migration ran too, just 3 seconds later.

Most Compose files only say depends_on: [db]. That waits for the database container to start, not for the schema.

Docker's docs say so plainly: Compose waits until a dependency is running, not until it is ready (Docker docs).

The fix is well known: a healthcheck on Postgres, a one-shot migration service, and condition: service_completed_successfully on the app. What the popular guides skip is what happens when the gate itself misfires. On a real deploy, it misfires on the first try. This post shows the file that works, and why the first version didn't.

What you're building

db (postgres:16-alpine)          stage 1
  │  healthcheck: pg_isready over TCP
  ▼  condition: service_healthy
migrate (one-shot job, exits 0)  stage 2
  │  waits for DNS + port, then runs idempotent SQL
  ▼  condition: service_completed_successfully
api (PostgREST, serves /todos)   stage 3

The API is PostgREST, which turns a Postgres schema into a REST API. It's a good fit here because it reads the schema at boot. If the migration hasn't run, there is nothing to serve.

Hubfly's composer turned these 3 services into 3 deploy stages. It marked migrate as a Job with restart policy Never, because of restart: "no".

Step 1: Postgres with a healthcheck that tells the truth

db:
  image: postgres:16-alpine
  environment:
    POSTGRES_DB: app
    POSTGRES_USER: app
    POSTGRES_PASSWORD: change-me   # replace before you deploy
  volumes:
    - pgdata:/var/lib/postgresql/data
  healthcheck:
    test: ["CMD-SHELL", "pg_isready -h 127.0.0.1 -U app -d app"]
    interval: 5s
    timeout: 3s
    retries: 10

Note the -h 127.0.0.1. Without it, pg_isready checks the Unix socket.

On first boot, the official image starts a temporary server to create your database. In the container logs, that temporary server listens only on the Unix socket. The real server came up afterwards with listening on IPv4 address "0.0.0.0", port 5432.

A socket check could go green during that setup window, so check over TCP as a precaution. A TCP check only passes once other containers can actually connect.

Step 2: a migration job that waits, then runs idempotent SQL

migrate:
  image: postgres:16-alpine
  restart: "no"
  environment:
    PGHOST: "{{service:db.host}}"
    PGUSER: app
    PGPASSWORD: change-me
    PGDATABASE: app
  command:
    - sh
    - -c
    - |
      timeout 60 sh -c 'until pg_isready -t 2; do echo "waiting for db"; sleep 2; done' || exit 1
      psql -v ON_ERROR_STOP=1 \
        -c "CREATE TABLE IF NOT EXISTS todos (id serial PRIMARY KEY, task text NOT NULL, done boolean NOT NULL DEFAULT false)" \
        -c "DO 'BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = ''web_anon'') THEN CREATE ROLE web_anon NOLOGIN; END IF; END'" \
        -c "GRANT USAGE ON SCHEMA public TO web_anon" \
        -c "GRANT SELECT ON todos TO web_anon" \
        -c "INSERT INTO todos (task) SELECT 'ship the migration gate' WHERE NOT EXISTS (SELECT 1 FROM todos)"
  depends_on:
    db:
      condition: service_healthy

Three details matter here.

1. The wait loop. This is the line that turns a failed deploy into a working one. More on why below. The timeout 60 keeps a broken database from hanging the rollout forever; after a minute the job exits 1 and the gate stays closed.

2. ON_ERROR_STOP=1. Without it, psql happily continues past a failed statement and exits 0. Your gate would open on a half-migrated schema.

3. Every statement is safe to re-run. The job runs on every deploy, and the volume keeps your data between deploys. Run it twice against the same database and the second run prints NOTICE: relation "todos" already exists, skipping and INSERT 0 0, then exits 0.

{{service:db.host}} is Hubfly's service reference. At deploy time it became the database's private hostname, db-1-7befe5b4.eucentral.hubfly.internal.

On plain Docker Compose, replace {{service:db.host}} with the service name db in both places: PGHOST: db and PGRST_DB_URI: postgres://app:…@db:5432/app.

The DO '...' block uses ordinary quotes instead of $$. That's deliberate: Compose treats $ as variable interpolation, and quoted SQL dodges the whole escaping question.

Step 3: the app waits for the job's exit code

  api:
    image: postgrest/postgrest:v12.2.3
    environment:
      PGRST_DB_URI: "postgres://app:change-me@{{service:db.host}}:5432/app"
      PGRST_DB_SCHEMAS: public
      PGRST_DB_ANON_ROLE: web_anon
      PGRST_SERVER_PORT: "3000"
    ports:
      - "3000:3000"
    depends_on:
      migrate:
        condition: service_completed_successfully

volumes:
  pgdata:

service_completed_successfully means exit code 0, nothing else. If the job exits 1, the API is never created. That's the whole point: a bad migration stops the release instead of shipping it.

The anonymous role gets SELECT only, so a POST /todos from the browser returns 401 with permission denied for table todos.

For production, have PostgREST log in as a dedicated low-privilege authenticator role instead of the app owner. This file uses one user to stay short.

Here's the complete file:

services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: change-me
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h 127.0.0.1 -U app -d app"]
      interval: 5s
      timeout: 3s
      retries: 10

  migrate:
    image: postgres:16-alpine
    restart: "no"
    environment:
      PGHOST: "{{service:db.host}}"
      PGUSER: app
      PGPASSWORD: change-me
      PGDATABASE: app
    command:
      - sh
      - -c
      - |
        timeout 60 sh -c 'until pg_isready -t 2; do echo "waiting for db"; sleep 2; done' || exit 1
        psql -v ON_ERROR_STOP=1 \
          -c "CREATE TABLE IF NOT EXISTS todos (id serial PRIMARY KEY, task text NOT NULL, done boolean NOT NULL DEFAULT false)" \
          -c "DO 'BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = ''web_anon'') THEN CREATE ROLE web_anon NOLOGIN; END IF; END'" \
          -c "GRANT USAGE ON SCHEMA public TO web_anon" \
          -c "GRANT SELECT ON todos TO web_anon" \
          -c "INSERT INTO todos (task) SELECT 'ship the migration gate' WHERE NOT EXISTS (SELECT 1 FROM todos)"
    depends_on:
      db:
        condition: service_healthy

  api:
    image: postgrest/postgrest:v12.2.3
    environment:
      PGRST_DB_URI: "postgres://app:change-me@{{service:db.host}}:5432/app"
      PGRST_DB_SCHEMAS: public
      PGRST_DB_ANON_ROLE: web_anon
      PGRST_SERVER_PORT: "3000"
    ports:
      - "3000:3000"
    depends_on:
      migrate:
        condition: service_completed_successfully

volumes:
  pgdata:

Deploy it on Hubfly

1. Create a project, open Create → Compose Stack, choose the YAML tab, paste the complete file from the end of Step 3 and click Import YAML.

2. Check the canvas: 3 services, the pgdata volume, and 2 DEPENDS arrows. The composer's monthly estimate for this stack on the shared tier was $0.01.

3. Click Deploy Stack and watch the activity log.

4. On the api container, open Network → Add Domain, pick port 3000, and create the subdomain.

5. Open https://<your-subdomain>.eu1.hubfly.app/todos.

You should get this back:

[{"id":1,"task":"ship the migration gate","done":false}]

A repeat GET /todos from the browser comes back in about 271 ms end to end.

Note: ports: "3000:3000" also creates a public TCP endpoint on tcp.eu1.hubfly.app by itself. That's fine for an API. Never add ports: to db.

What the 59 seconds looked like

Hubfly marked db healthy about 2 seconds after it deployed, on the failed deploy and the working one alike. So don't rely on the healthcheck alone. The wait loop is what makes the rollout work.

Why the first deploy failed

The first version of the file had no wait loop and no TCP healthcheck. Here's what happened.

db went healthy at 06:28:24. migrate deployed at 06:28:36 and failed 2 seconds later. The API was never created, so the gate did its job. But why did a migration fail against a healthy database?

The job's container was rolled back, taking its logs with it. So the cause can't be proven, but 2 clues from the next deploy point to it.

The migration job's own first line, with the wait loop in place:

db-1-7befe5b4.eucentral.hubfly.internal:5432 - no response
waiting for db
db-1-7befe5b4.eucentral.hubfly.internal:5432 - accepting connections
CREATE TABLE
...

And PostgREST's first 2 seconds of life (container logs are in UTC; the deploy table is CAT, UTC+2):

04:33:10 Failed to query the PostgreSQL version ... could not translate host name
         "db-1-7befe5b4.eucentral.hubfly.internal" to address: Name does not resolve
04:33:12 Successfully connected to PostgreSQL 16.15
04:33:14 Schema cache loaded 1 Relations

On the next deploy, a freshly started container could not resolve the database's private hostname for about 2 seconds. PostgREST shrugs that off because it retries. A one-shot psql doesn't retry. It fails, exits non-zero, and takes your deploy down with it.

That's not a Hubfly quirk you can ignore elsewhere. On any orchestrator, "the dependency is healthy" and "my container can reach it right now" are two different facts. A job that runs once must check the second one itself.

What can go wrong

1. The job fails in 2 seconds and you can't see why. A failed job may be rolled back with its logs. Add the wait loop from Step 2, and make the job print what it's doing (echo "waiting for db"). If it still fails, the next run's logs will show whether it's DNS, the port or the SQL.

2. "Healthy" doesn't mean "reachable".pg_isready without -h checks the Unix socket, and the first-boot setup server listens only there. Use pg_isready -h 127.0.0.1 -U app -d app, and still keep the wait loop in the job: Hubfly marks db healthy about 2 seconds after deploy either way.

3. A failed rollout leaves an old database behind. After the failed first deploy, the rollback of db itself failed (Rollback failed for 'db'). The old db was left behind, asleep and still attached to the volume. The next deploy then created db-1 next to it, on the same pgdata volume.

Two Postgres servers on one data directory is how you lose data. Before you redeploy after a failure, open the project, and stop or remove any leftover database container.

4. The migration isn't idempotent. The job runs on every deploy. CREATE TABLE without IF NOT EXISTS will fail on deploy number 2 and block every release after it. Guard every statement, or use a migration tool that records what it applied (Prisma's migrate deploy, Flyway, golang-migrate, Alembic).

Takeaway

service_completed_successfully is a good gate. It only works if the job behind it is honest: it waits for the database itself, stops on the first error, and is safe to run again. Put those 3 properties in your migration job and a broken schema stops the release instead of reaching users.

Deploy this

Paste the Compose file into a new Hubfly project (Create → Compose Stack → YAML) and click Deploy Stack. The shared tier needs no card. Change change-me first.

What it costs

The composer estimated \(0.01/month for this stack on the shared tier. That matches a 1 GB volume: 1 GB × \)0.00001536 per GB-hour × 730 h = $0.011 (the free tier includes 1 GB of storage).

Shared containers auto-sleep, and their compute is free within the free tier's 360 hours a month. Two containers kept awake all month would use 1,460 hours.

If you keep db and api awake using a dedicated container (0.5 vCPU, 256 MB):

CPU: 0.5 = $1.46

RAM: 256 MB = $0.36

Per container: \(1.94/month; for db + api: \)3.88/month, plus $0.11 of storage

The migration job runs for a couple of seconds per deploy, which rounds to $0.00.

Read next:

• Compose Stacks on Hubfly: dependency conditions and {{service:...}} references

• ComposeSpec JSON reference: jobs, stages and restart policies

• Hubfly documentation home: volumes, networking and private DNS

• Deploy Odoo on Hubfly with PostgreSQL and persistent storage: another Postgres stack with a volume