DEV Community: octave Nkurunziza

Fixed vs pay-as-you-go hosting: find your break-even point

octave Nkurunziza — Thu, 22 Oct 2026 08:06:41 +0000

Originally published on the Hubfly space blog.

TL;DR

What you get: a two-line formula that tells you when a fixed plan beats pay-as-you-go, why memory (not CPU) sets the floor of most bills, and three common apps priced on six platforms (prices from official pages, 21 Oct 2026).

The short answer: a fixed plan wins when your app is small, steady and fits a plan size exactly. Paying for real CPU use wins when traffic is spiky and CPU sits idle. Sleeping when idle beats both for apps nobody uses at night.

Who it's for: developers and founders picking a host for an API, a side project or a small SaaS. About 12 minutes to read.

Your app costs $7 a month on one platform, $6.09 on another and $2.19 on a third. All three pages say they're cheap, and all three are right for someone. The trouble is that "usage-based" and "fixed" hide very different meters, and picking the wrong one means paying every month for capacity you never touch, or getting a surprise bill after a traffic spike.

In this guide you'll learn what each pricing model actually charges for, price three common apps on six platforms, and get a two-line formula to find the point where switching models saves you money. It matters because hosting is a bill you pay forever: a $5 difference is $60 a year per service, and most apps run more than one service.

Try it on Hubfly space: the free tier gives you 360 hours a month on the shared tier, no card needed.

The three ways hosts charge you

Every platform in this guide falls into one of three groups. Knowing which one you're on tells you what to watch.

1. Fixed plans (you pay for a size). You pick a box, such as 0.5 CPU and 512 MB, and pay a flat monthly price whether the app is busy or idle. Render ($7 for its "less than 1 CPU" / 512 MB instance), Heroku ($7 Basic dyno, 0.5 GB) and DigitalOcean App Platform ($5 for 1 vCPU / 512 MiB) work this way. Why it matters: the bill is easy to predict, but if your app needs 600 MB you jump to the next size and pay for CPU you didn't need.

2. Pay for what's allocated, while it runs. You still choose a size, but you're billed by the hour or second only while the app is running. Stop it, or let it sleep, and compute billing stops. Fly.io bills started Machines "by the second while running" ($3.69 per 30 days for shared-cpu-1x with 512 MB in its cheapest regions). Hubfly space works the same way: $0.004 per vCPU-hour and $0.002 per GB-hour of allocated memory, billed only while the container is awake. Why it matters: you still pick a size, so oversizing still costs you, but idle hours can be free.

3. Pay for what's consumed. You set a maximum, and the platform meters the CPU and memory your app actually uses. Railway is the clearest example: $0.00000772 per vCPU-second and $0.00000386 per GB-second, which is about $20.29 per vCPU and $10.14 per GB of RAM over a 730-hour month. The Hobby plan has a $5 minimum that includes $5 of usage. Why it matters: an app that averages 5% of a CPU pays for 5%, so you never pay for headroom you don't use.

A fourth group, request-based platforms like Vercel and Cloudflare Workers, bills per request and execution time. It's great for front ends and functions, but most apps that need a database and a long-running process end up on one of the first three, so this guide focuses on them.

The meter nobody talks about: memory

"Pay only for what you use" sounds like your bill drops to almost nothing when the app is quiet. It doesn't, and the reason is memory.

CPU use rises and falls with traffic. Memory doesn't. A Node or Python app loads its code, libraries and caches at startup and holds them until it stops. So a small API can hold hundreds of megabytes of RAM at 3 a.m. with zero requests.

On Railway, 0.5 GB held for a whole month costs 0.5 × $10.14 = $5.07, even if CPU is close to zero. That's already past the $5 Hobby minimum before you've used a single CPU cycle. So when you compare platforms, put your app's idle memory into the math first. It sets your floor.

The same logic applies to allocated platforms in a different way: on Fly.io and Hubfly space you pay for the memory you reserve, not what you use, so reserving 2 GB for an app that needs 500 MB is wasted money every hour it runs.

Find your break-even point in two lines

You don't need a spreadsheet. If you're comparing a fixed plan against consumption pricing, solve this:

consumption cost = (average vCPU used × CPU price per month)
                 + (average GB of RAM held × RAM price per month)

break-even CPU   = (fixed plan price − RAM cost) ÷ CPU price per month

Example: Render's $7 plan vs Railway, for an app that holds 512 MB.

Railway RAM cost: 0.5 GB × $10.14 = $5.07
Room left before you hit $7: $7 − $5.07 = $1.93
Break-even CPU: $1.93 ÷ $20.29 = 0.095 vCPU

If your app averages less than about 10% of one CPU, Railway is cheaper than Render's $7 plan. Above that, the fixed plan wins, as long as Render's smallest instance is enough for your peaks.

To get your own numbers, check your current host's metrics page for average CPU (not peak) and average memory over a normal week.

Three apps, six platforms

All prices below come from each vendor's official pricing page on 21 Oct 2026, for compute only. Bandwidth, databases and disks are left out so the comparison stays like-for-like; see the notes after each table. A "month" is 730 hours unless the vendor states otherwise (Fly.io quotes 30 days).

App 1: a small API that must stay on

A customer-facing API: 512 MB of RAM, averages 0.05 vCPU, can't sleep because a cold start would make users wait.

Platform	What you buy	Monthly cost	How it's worked out
Hubfly space	Dedicated 0.5 vCPU / 512 MB, 24/7	$2.19	(0.5 × $0.004 + 0.5 × $0.002) × 730 h
Fly.io	shared-cpu-1x / 512 MB (iad, ewr)	$3.69 per 30 days	List price
DigitalOcean	1 vCPU / 512 MiB, fixed	$5.00	List price
Railway (Hobby)	Measured use	$6.09	0.05 × $20.29 + 0.5 × $10.14 = $6.09, above the $5 minimum
Render	"Less than 1 CPU" / 512 MB	$7.00	List price
Heroku	Basic dyno, 0.5 GB	$7.00	List price

What this shows: for a small, steady app, allocation pricing with low hourly rates wins, and fixed plans are close behind. Consumption pricing gives you the least advantage here because the app holds its memory all month. Note that Fly.io lists cheaper prices only for its lowest-priced regions, and DigitalOcean includes 50 GiB of outbound transfer in that $5, which matters if your API sends a lot of data.

App 2: an internal tool used a few hours a week

An admin dashboard or staging app: about 50 hours awake a month, 512 MB while running, cold starts are fine.

Platform	Setup	Monthly cost	How it's worked out
Hubfly space	Shared tier (0.3 vCPU / 256 MB), auto-sleep	$0 if it fits 256 MB	Free within 360 shared-tier hours a month
Railway	Measured use, sleeping when idle	$0.42 of usage	(0.05 × $0.00000772 + 0.5 × $0.00000386) × 180,000 s. Fits Railway's Free plan ($1 a month after the trial); $5 on Hobby because of the minimum
Fly.io	shared-cpu-1x / 512 MB, auto-stop	about $0.26 + stopped disk	$3.69 ÷ 720 h × 50 h; stopped Machines pay $0.15 per GB-month of rootfs
DigitalOcean	1 vCPU / 512 MiB	$5.00	The app stays on all month
Render	Free instance, sleeps when idle	$0	750 free instance hours per workspace a month; spins down after 15 min without inbound traffic, about 1 min to wake. A paid 0.5 CPU / 512 MB instance doesn't sleep, so it's $7.00
Heroku	Eco dyno, 0.5 GB	$5.00	Flat $5 for a pool of 1,000 hours shared by all your Eco apps; sleeps after 30 min of inactivity. Basic ($7) stays on

What this shows: for apps that are idle most of the month, the ability to sleep matters far more than the price per hour. Every platform that sleeps keeps usage under $1, though Railway Hobby still bills its $5 minimum and Heroku Eco is a flat $5. Plans that stay on charge full price for an app used 7% of the time. On Hubfly space, a shared-tier container's cost breakdown in the dashboard reads "Shared tier is free of charge": $0.00 an hour and $0.00 a month. If the tool needs more than 256 MB, a dedicated 0.5 vCPU / 512 MB container costs $0.003 an hour while awake: about $0.15 for 50 hours with Auto Sleep on, or $2.19 left on around the clock.

App 3: a busy API with steady load

A production API that holds 1 GB of RAM and averages 0.6 vCPU all day, every day.

Platform	What you buy	Monthly cost	How it's worked out
Hubfly space	Dedicated 1 vCPU / 1 GB, 24/7	$4.38	(1 × $0.004 + 1 × $0.002) × 730 h
Fly.io	shared-cpu-1x / 1 GB (iad, ewr)	$6.70 per 30 days	List price. Check Fly's CPU quota rules before running a steady 60% load on a shared CPU; a dedicated-CPU performance-1x Machine comes with 2 GB and is $33.00
DigitalOcean	1 vCPU / 1 GiB (not fixed CPU)	$12.00	List price
Railway	Measured use	$22.32	0.6 × $20.29 + 1 × $10.14
Render	1 CPU / 2 GB (the smallest instance is too small)	$25.00	List price
Heroku	Standard-2X, 1 GB	$50.00	List price

What this shows: once CPU stays busy, paying per vCPU-second of real use stops being a discount. At 0.6 vCPU, Railway costs almost as much as Render's next size up. Using the break-even formula against Render's $25 plan: ($25 − $10.14) ÷ $20.29 = 0.73 vCPU. Above 73% average CPU, the fixed plan is cheaper. Allocated pricing (Hubfly space, Fly.io) wins clearly here, as long as a shared CPU meets your load.

Where each model wins

Be honest about your app's shape before you pick a host. Here's where the other platforms do better than Hubfly space, or better than each other:

Railway wins on spiky traffic and odd sizes. If your app idles at 0.05 vCPU and jumps to 2 vCPU for an hour a day, consumption pricing bills that hour and nothing else, without you resizing anything. It also gives you hard spending limits, preview environments and built-in database backups.
Fly.io wins on global reach and scale-to-zero for any size. You can stop any Machine, not just a small free tier, and its reservation blocks cut 40% off for a year's commitment.
DigitalOcean wins on bundled bandwidth. Each plan includes outbound transfer (50 GiB on the $5 plan), and overage is $0.02 per GiB. For a download-heavy app that's easier to budget.
Render and Heroku win on predictability and maturity. A fixed $7 or $25 is easy to put in a budget, and both have long track records, managed Postgres and large ecosystems.
Hubfly space wins on low hourly rates and a free tier that sleeps. You pay $2.92 a month for a full vCPU and $1.46 per GB of RAM when running around the clock, with no seat or project fees. The trade-offs: you pay for what you allocate, so size containers carefully; and the free shared tier is small (0.3 vCPU / 256 MB).

What can go wrong

1. You sized for the peak, not the average. On fixed and allocated platforms, a 2 GB container for an app that needs 500 MB means paying four times too much, every hour. Fix: watch memory for a week, then set the size to your normal peak plus about 25%.

2. Your "sleeping" app never sleeps. Platforms decide an app is idle in different ways. Railway, for example, watches outbound traffic, so a database connection pool, a health-check pinger or a queue poller can keep it awake and billing. Fix: close idle connections, remove external uptime pings on non-critical apps, and confirm on the metrics page that the app actually stops.

3. The bill jumps after a traffic spike. That's consumption pricing doing its job, but it can still hurt. Fix: set a spending alert or limit before you need it. On Hubfly space you can set a monthly budget for each project in its settings, with alerts as you approach it.

Takeaway: match the model to your app's shape

Small, steady, always on: allocated or fixed pricing. Look for the lowest hourly rate that fits your memory.
Idle most of the time: anything that sleeps. The price per hour barely matters.
Spiky and unpredictable: consumption pricing, with a hard limit set.
Busy and steady: allocated pricing at low hourly rates, or a fixed plan sized exactly.

Go further on Hubfly space

Move an existing app over: follow How to move your app from Railway to Hubfly space, step by step, including copying your Postgres data.
Run your whole stack in one place: deploy a docker-compose.yml as-is with web, Postgres and Redis on private networking.
Price your own app: use the two rates on the Hubfly space pricing page ($0.004 per vCPU-hour, $0.002 per GB-hour) with the formula above. Storage is $0.011 per GB-month on the Standard tier.

Price your app on Hubfly space: start free on the shared tier (360 hours a month, no card), then switch a container to dedicated when it needs to stay on.

How to get a managed PostgreSQL database for about $2 a month

octave Nkurunziza — Thu, 22 Oct 2026 08:05:13 +0000

Originally published on the Hubfly space blog.

Running Postgres yourself means patching it, guarding the port and rotating passwords, or leaving your data on an app volume one bad redeploy from trouble.

TL;DR

What you get: a PostgreSQL 18 database that Hubfly space runs for you, with TLS on every connection, an IP allowlist, pgvector ready to install, and a connection string written straight into your app.

Who it's for: side projects, small SaaS apps and AI features that need Postgres but not a database admin.

Time needed: about 10 minutes. The database itself is ready in about a minute and a half.

Cost: about $2.02 a month for the smallest size. You can stop it and pay about $0.11 a month for storage.

In this guide you'll create a managed PostgreSQL database on Hubfly space, add vector search, lock it to your network and connect an app without copying a password anywhere. You'll know exactly what Hubfly space runs for you, what it still leaves to you, and what it costs to the cent.

Try it on Hubfly space →

What Hubfly space runs, and what you still own

Managed Databases are a new project type on Hubfly space. One managed project can hold several databases (PostgreSQL, MySQL or SQLite through libSQL) and Realtime servers.

Hubfly space does this	You still do this
Creates the server and its storage, picks where it runs	Choose the size and grow storage when you need it
Generates and encrypts passwords, refuses connections without TLS	Decide who may connect (IP allowlist, one user per app)
Start, stop, restart, resize, version updates, config changes with automatic rollback	Keep your own copies of the data (see the limits below)
Metrics, logs, sessions, query insights and alerts	Read them and act on them

You get an admin user that can create databases and users and read and write everything. It is not a superuser, so anything that needs superuser rights won't work.

Step 1: Create a managed project

Open the dashboard, click Create Project, give it a name like shop-data, and pick Managed service. There's no region to choose: Hubfly space places the database for you. Open Advanced Options and set a monthly budget if you want a spending alarm on this project.

The project opens on a page with three cards: Database, Realtime and Cache (Cache is marked Coming soon). Click Create a database.

Step 2: Pick the engine, size and name

The form has one section per decision:

Engine and version: PostgreSQL 18 is the default (17 and 16 are also offered).
Size: Nano (0.25 vCPU, 512 MiB) is enough for a prototype or a small app. PostgreSQL needs at least 512 MiB.
Storage: 10 GiB by default, from 1 to 500 GiB. It can grow later but never shrink, so start small.
Network & access: public access is on, and the allowlist is empty. You'll lock it down in Step 5.
Instance name: for example shop-db. It becomes part of the hostname.

The price panel updates as you change the form and splits the cost into compute, storage and management:

Click Create database. The page lists nine provisioning steps as they run, from "Reserving capacity" to "Registering hostname". Expect about a minute and a half until the status turns Running.

The header shows your hostname and port, such as shop-db-xxxx.db.hubfly.app:30010. Note the port: it is assigned to your instance and it is not 5432. Copy it from the page rather than guessing.

Step 3: Get your connection string

Open Connect. It shows the host, port, database (app), user (admin) and a hidden password. Reveal shows the password for a minute, and every reveal is written to the access log, so you can see who looked at it.

Under Connection string and snippets you can copy a ready-made string for URI, .env, psql, Prisma, Drizzle, Node (pg), Python, Go (pgx), JDBC or PHP (PDO). All of them include sslmode=require, because the database refuses unencrypted connections. To also verify the server's identity, download the instance's CA certificate from the same page.

Step 4: Add vector search with pgvector

If you're building search, recommendations or an AI feature, you can keep your embeddings next to the rest of your data. Open Extensions, find vector (pgvector 0.8.7), click Install and confirm. PostGIS, pg_trgm, pgcrypto, uuid-ossp and pg_stat_statements are on the same list.

Now open the SQL editor. It opens in read-only mode every time, which protects you from a stray DELETE. Turn Read-only off, then run:

CREATE TABLE products (id bigserial PRIMARY KEY, name text NOT NULL, embedding vector(3));

INSERT INTO products (name, embedding) VALUES
  ('red running shoes', '[0.9,0.1,0.0]'),
  ('blue trail shoes',  '[0.8,0.2,0.1]'),
  ('wool winter hat',   '[0.0,0.1,0.9]');

SELECT name, round((embedding <=> '[1,0,0]')::numeric, 3) AS distance
FROM products
ORDER BY embedding <=> '[1,0,0]'
LIMIT 2;

Each statement gets its own result tab. The query returns the two shoes, closest first:

Real embeddings have hundreds of dimensions instead of 3, but the query is the same. The editor works through Hubfly space, so it needs no allowlist entry and no local client.

Step 5: Lock it to your network

An empty allowlist means anyone with the password can try to connect from anywhere. Open Network, click Add entry, and add your office or server range, for example 203.0.113.0/24 with the label office. Add my IP fills in the address you're browsing from. Click Save allowlist. The change applies in about 10 seconds and the status changes to "Public, limited to 1 allowed range".

You can add up to 64 addresses or CIDR ranges. Hubfly space enforces the list in its proxy, before a connection reaches Postgres.

One catch: connected Cell apps reach the database through the same public endpoint, so the allowlist applies to them too. After you restrict the list, add the addresses your apps connect from and confirm they still connect. Keep Public access on while apps use the connection string, because it points at the public endpoint.

Step 6: Connect your app without copying passwords

Open Apps and click Connect an app. Pick the Cell project that runs your app, keep the variable name DATABASE_URL, and leave Create a dedicated user ticked with Read & write. Click Connect app.

Hubfly space creates a separate database user for the app and writes the full connection string into the project as a Secret variable:

Why a dedicated user? If you ever rotate the admin password, this app keeps working. If you disconnect the app, its user is dropped. Redeploy the app after connecting: apps read variables at deploy time. Deleting the database later also removes DATABASE_URL from the project, so reconnect or redeploy the app with a new database first.

What it costs

Managed Databases use the same rates as dedicated Cell resources, plus a 30% management fee on CPU and memory while the database runs. Monthly figures use 730 hours.

For Nano with 10 GiB of storage:

Compute: 0.25 vCPU × $0.004 + 0.5 GiB × $0.002 = $0.002 per hour, plus the 1 GiB system disk at $0.00001536 per GB-hour = $0.00201536
Management: 30% × $0.002 = $0.0006 per hour
Storage: 10 GiB × $0.00001536 per GB-hour = $0.0001536 per hour
Total: $0.00276896 per hour × 730 = about $2.02 a month

Size	vCPU / memory	Per month (10 GiB)
Nano	0.25 / 512 MiB	$2.02
Small	0.5 / 1 GiB	$3.92
Medium	1 / 2 GiB	$7.72

A stopped database pays only for storage: about $0.11 a month for 10 GiB. The database is billed from your account balance. It isn't part of the free tier's 360 hours. If your balance runs out, Hubfly space stops the database and starts it again after you top up.

The limits, honestly

No automatic backups yet. There are no snapshots, replicas or point-in-time recovery. One-click exports live on the Backups & exports page. If it shows "Exports are not available for this instance yet.", take your own dumps with your usual Postgres tools over the TLS connection and keep them somewhere you control.
One server in one location, chosen by Hubfly space. No high availability. A restart or version update briefly drops connections.

Who this is NOT for

Skip it for now if losing the last few hours of data would hurt your business, or if you need replicas, a specific region for data-residency rules, or superuser access. Pick a provider with point-in-time recovery until automatic backups arrive.

What can go wrong

"cannot execute CREATE TABLE in a read-only transaction" (error 25006). The SQL editor starts in read-only mode. Switch Read-only off before writing, and switch it back when you're done.
Your client or app times out. Check the port (it isn't 5432) and the allowlist. Once the list has entries, only those ranges can connect, your laptop and your apps included.
Your app still can't see DATABASE_URL. Apps read variables at deploy time. Redeploy after you connect, disconnect or rotate credentials.

Go further on Hubfly space

Run untrusted or AI-generated code next to it with one container per task.
Add live updates with Realtime, a Pusher-compatible WebSocket server you create from the same managed project (docs home).
Store product images on Storage and resize them with a URL.
Ship every push automatically with GitHub Actions and a deploy webhook.
Read the full Managed Databases guide for MySQL, libSQL tokens and configuration changes.

Start free

Create a free account (no card needed, 360 hours of shared compute a month for your app), add balance when you're ready for the database, and have Postgres with pgvector running in about 10 minutes.

Try it on Hubfly space: start free →

Deploy your own MCP server with HTTPS and an access key

octave Nkurunziza — Wed, 21 Oct 2026 12:20:04 +0000

Originally published on the Hubfly space blog.

TL;DR

What you get: your own MCP server on a public HTTPS address, locked with an access key, and connected to Claude Code, Cursor and Codex.

Who it's for: developers who built (or want to build) an MCP server and are tired of it only working on localhost.

Time: about 15 minutes. Cost: free on the shared tier (360 compute hours a month, no card); about $2.25 a month always on (dedicated 0.5 vCPU, 512 MB).

Your MCP server works great on your laptop. Then you open Cursor on your other machine, or a teammate asks for it, and it's gone. Local servers die when your laptop sleeps, and you end up copying the same setup to every computer.

In this guide you'll put one MCP server online, behind HTTPS and an access key, and point every AI tool you use at the same address. One server, one place to update it, and nobody else can call your tools.

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

What you'll build

Claude Code ─┐
Cursor ──────┼──► https://your-server.eu1.hubfly.app/mcp ──► access key check ──► your MCP server (Python)
Codex ───────┘                                              (at the edge)         (Hubfly space Cell container)

A small Python MCP server with two tools, add_note and list_notes. Swap in your own tools later; the deploy steps stay the same.

Step 1: Write the server

Install the official Python SDK on your machine to try it locally first:

pip install "mcp==2.3.0"

Create server.py:

import os

from mcp.server import MCPServer

mcp = MCPServer("notes")
notes: list[str] = []


@mcp.tool()
def add_note(text: str) -> str:
    """Save a short note."""
    notes.append(text)
    return f"Saved note #{len(notes)}"


@mcp.tool()
def list_notes() -> list[str]:
    """Return every saved note."""
    return notes


if __name__ == "__main__":
    mcp.run(
        transport="streamable-http",
        host="0.0.0.0",
        port=int(os.environ.get("PORT", "8000")),
    )

Two lines matter more than they look:

transport="streamable-http" makes the server speak MCP over HTTP instead of stdin/stdout. Remote clients can only reach an HTTP server.
host="0.0.0.0" makes it listen on every network interface. The SDK's default is 127.0.0.1, which only accepts connections from inside the container itself, so the platform's proxy can't reach it and you get a 502 error.

The server answers on /mcp, so locally it lives at http://127.0.0.1:8000/mcp.

Note on the SDK version: version 2 of the mcp package renamed FastMCP to MCPServer. Many tutorials still use from mcp.server.fastmcp import FastMCP, which fails on 2.x. Pin the version so a future release doesn't change things under you.

Step 2: Add a Dockerfile

Put this Dockerfile next to server.py:

FROM python:3.12-slim
WORKDIR /app
RUN pip install --no-cache-dir "mcp==2.3.0"
COPY server.py .
EXPOSE 8000
CMD ["python", "server.py"]

Installing the package during the build (not at startup) keeps restarts fast: the container starts the server straight away instead of downloading packages each time.

Push both files to a GitHub repository.

Step 3: Deploy it on Hubfly space

Sign in to the Hubfly space dashboard and click Create Project. Give it a name like notes-mcp, pick a region close to you, and (optional) open Advanced Options to set a monthly budget cap, for example $10.
In the project, click Create → Create Container. Name it mcp-server.
Under Deployment Source, choose Git repository, connect GitHub through the GitHub App, and pick your repository. A Dockerfile in the repository root is used for the build.
On Resources, keep Shared Tier (Free): 0.3 vCPU and 256 MB RAM, enough for a small server.
Click through to Review and press Deploy Container. The container page shows each deploy stage as it runs.

Open the Logs tab. When you see this line, the server is ready:

INFO:     Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

Step 4: Give it a public HTTPS address

Right now the server only exists on the private network. To reach it from your laptop:

Open the container's Network tab and click Add Domain.
Keep Auto Endpoint. Under Suggested ports, the live scan shows 8000 · Open now. Click it.
Leave TLS / SSL and Force HTTPS on, and click Create Subdomain.

The address is named after your container, for example https://mcp-server.eu1.hubfly.app. Your MCP endpoint is that address plus /mcp.

Check that it answers. This is the MCP "hello" (the initialize call):

curl -i https://<your-address>/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"1"}}}'

You get HTTP 200, an mcp-session-id header and a reply that starts like this:

event: message
data: {"jsonrpc":"2.0","id":1,"result":{"capabilities":{...},"protocolVersion":"2025-06-18","serverInfo":{"name":"notes","version":""}}}

The round trip takes well under a second once the server is awake.

Don't stop here. At this point anyone who finds the address can call your tools. Public addresses get visits from scanners within minutes of being created, so lock it before you connect anything.

Step 5: Lock it with an access key

Hubfly space can check an access key at the edge, before the request ever reaches your container. Your Python code doesn't change.

Go back to the project overview and click the Firewall box above your container. This opens Security & Protection Studio.
Check that your domain is selected in the domain picker, then open the Identity Access Control tab.
Under Access Authentication Mode, choose API Key Only, switch Policy Enforcement State on, and click Save Policy Settings. The status changes from Permissive to Enforced.
Open the API Keys tab. Enter a name (for example laptop-clients), leave Allowed Paths empty, optionally set an expiry date, and click Generate Secret Key.
Copy the key (it starts with hfa_live_). It is shown only once, so save it in your password manager right away.

Now run the curl from Step 4 again without a key. You get:

HTTP/1.1 401
{"error":"identity_access_required","request_id":"..."}

A made-up key gets the same 401. These requests are stopped at the edge: they never show up in your container's logs, so a flood of bad requests doesn't cost your server any work.

To call it with the key, add one header:

-H "X-HubFly-Access-Key: $MCP_KEY"

Keep the key in an environment variable or your password manager, never in a Git repository. Issue one key per person or machine, with an expiry date, so you can retire one without breaking the others.

Step 6: Connect Claude Code, Cursor and Codex

First, put the key in your shell so it stays out of config files:

export MCP_KEY="hfa_live_..."   # paste your key

Claude Code (one command):

claude mcp add --transport http notes https://<your-address>/mcp \
  --header "X-HubFly-Access-Key: $MCP_KEY"

Run /mcp inside Claude Code to see the server and its two tools.

Cursor: add this to ~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project):

{
  "mcpServers": {
    "notes": {
      "url": "https://<your-address>/mcp",
      "headers": { "X-HubFly-Access-Key": "${env:MCP_KEY}" }
    }
  }
}

Codex: add this to ~/.codex/config.toml:

[mcp_servers.notes]
url = "https://<your-address>/mcp"
env_http_headers = { "X-HubFly-Access-Key" = "MCP_KEY" }

env_http_headers reads the value from the MCP_KEY environment variable (use http_headers instead for a fixed value). The key name matters: Codex's setting is http_headers/env_http_headers, not the headers you use in Cursor, and a request without the key gets a 401.

Ask your client to list its MCP tools; you should see add_note and list_notes. Then try "add a note: buy oat milk" followed by "list my notes". Every client you connect uses the same server, so they share the same notes. If a client reports 401, the header name or key is wrong.

What about claude.ai and Claude Desktop connectors? Custom connectors there support OAuth or no auth. Fixed headers are a limited beta for some organizations, and a custom header name like X-HubFly-Access-Key needs approval from Anthropic first. For those apps, plan on OAuth.

What can go wrong

1. 421 Misdirected Request with "Invalid Host header". This happens if you run the server with Uvicorn directly (uvicorn.run(mcp.streamable_http_app(), ...)) instead of mcp.run(...). In that mode the SDK turns on DNS-rebinding protection and only accepts Host: 127.0.0.1 or localhost, so every request through your public address is refused. Fix it by allowing your address:

from mcp.server.transport_security import TransportSecuritySettings

app = mcp.streamable_http_app(
    transport_security=TransportSecuritySettings(
        allowed_hosts=["mcp-server.eu1.hubfly.app"]  # your address
    )
)

Note that once you set allowed_hosts, local requests to 127.0.0.1 are refused with the same 421, so add "127.0.0.1:8000" to the list if you also run it locally. The mcp.run(transport="streamable-http", host="0.0.0.0") setup from Step 1 doesn't hit this.

2. 502 Bad Gateway from the address. The server is listening on 127.0.0.1, usually because host="0.0.0.0" is missing. Add it and redeploy. If Suggested ports in the Add Domain dialog shows nothing, the server isn't listening yet: check the Logs tab.

3. The client times out on the first call of the day. Shared-tier containers suspend after 15 minutes of inactivity, and the first call after a pause can be slow. Some clients give up quickly (Codex waits 10 seconds by default; raise it with startup_timeout_sec = 30 in the same TOML block). If you use the server all day, move it to the dedicated tier with Auto Sleep off.

Bonus: notes disappear after a redeploy. This example keeps notes in memory, and everything outside a volume is wiped when the container restarts or redeploys. For real data, use a database (see below). Also keep an eye on memory: this small server already uses most of the shared tier's 256 MB, so heavier tools need a dedicated container.

What it costs

Shared tier: free within the 360 compute hours a month included in the free tier. The project's budget panel shows a projected $0.00/month for this setup.
Always on (dedicated, 0.5 vCPU, 512 MB RAM, 5 GB disk, Auto Sleep off): about $2.25 a month.
- CPU: 0.5 × $0.004 × 730 h = $1.46
- RAM: 0.5 GB × $0.002 × 730 h = $0.73
- Disk: 5 GB × $0.00001536 × 730 h = $0.06
The access key check, the HTTPS address and the certificate are free.

Takeaway

Getting an MCP server off localhost takes four things: speak HTTP (streamable-http), listen on 0.0.0.0, give it an HTTPS address, and check a key before requests reach your code. Do those once and every AI tool you use shares the same tools.

Go further on Hubfly space

Give your tools real data: add a PostgreSQL database from the templates with a volume so data survives redeploys, and connect to it over the private network. See the Compose docs and Docker health checks that catch real problems for a Compose setup.
Let your team in with their login instead of keys: switch the route to Login or API Key so teammates sign in in the browser while tools keep using keys. See Identity Access.
Let your coding agent deploy for you: the Hubfly space AI skill teaches Claude Code, Codex and Cursor to deploy and update projects with the hubfly CLI.

Try it on Hubfly space → Free tier, 360 compute hours a month, no card.

How to deploy on every push with GitHub Actions and a webhook

octave Nkurunziza — Wed, 21 Oct 2026 12:18:48 +0000

Originally published on the Hubfly space blog.

TL;DR

What you get: every push to main redeploys your container on Hubfly space, and you can send a rollback action when a release goes bad.

Who it's for: developers who build images or test code in GitHub Actions (or GitLab CI) and still redeploy by hand.

Time: about 15 minutes.

Cost: deploy webhooks are free. You pay only for the container itself; the shared tier is free for 360 hours a month.

Your app is live, but every change still ends with you opening the dashboard and clicking Redeploy. That's slow, and it's how the wrong build reaches your users on a Friday evening. In this guide you'll connect GitHub Actions to Hubfly space with a signed deploy webhook, so every push to main goes live on its own once your tests pass, and you can send a rollback when a release goes bad.

Try it on Hubfly space. Start free, 360 hours included →

What a deploy webhook does

A deploy webhook is an address your CI calls when a build is ready. Hubfly space then does one action on your container: pull the new image or commit, update its settings, restart it, or roll it back. Pushing an image to a registry never redeploys anything by itself, so the webhook is the missing "now ship it" step.

Each webhook has three settings that matter:

Setting	What it controls	Pick
Security mode	How Hubfly space checks the caller	HMAC-SHA256 for anything real
Allowed actions	What the caller may do	Only what your pipeline needs
IP allowlist	Where calls may come from	Your fixed runner IPs, if you have them

The three security modes differ a lot:

Mode	How the call is checked	Actions the dashboard offers
Basic	Token inside the URL	Image Pull only
Standard	Token inside the URL	Image Pull, Provisioning, Hard Restart
HMAC-SHA256 (secure)	Signed timestamp + body, no token in the URL	Every action, including Config Update and Rollback Recovery

Why it matters: with Basic or Standard, anyone who sees the URL (a leaked build log is enough) can trigger it. With HMAC-SHA256 the URL alone is useless. Each request must be signed with a secret, and the signature expires after five minutes, so a captured request can't be replayed later.

Step 1: Create the webhook

Open your project, then the Pipeline tab, and click Create webhook.

Give it a clear Webhook name, such as GitHub Actions deploy, and an optional description.
Under Target Container Context, pick the container this webhook may deploy. Leave it on All Containers (Project Scope) only if one pipeline deploys several services; then every request must say which container it means.
Click Next Step.
Choose HMAC-SHA256.
Under Allowed Operation Permissions, turn on Image Pull and Rollback Recovery. Add Config Update only if your pipeline also changes environment variables. Leave Deprovisioning off: a deploy pipeline never needs to delete anything.
If your CI runs on a machine with a fixed public IP (a self-hosted runner, a build server), enter it under IP Allowlist Restriction.
Click Register Webhook.

A dialog then shows the HMAC Signing Secret Key and the Deployment Pipeline URL Target. The secret is shown once. Copy both now; if you lose the secret, delete the webhook and create a new one. Webhooks can't be edited after you create them, so changing the allowed actions also means creating a new one.

Step 2: Store the values in GitHub

In your repository, open Settings → Secrets and variables → Actions and add two repository secrets:

HUBFLY_WEBHOOK_URL: the URL you copied (it looks like https://api.hubfly.space/api/webhooks/deploy/whk_…).
HUBFLY_WEBHOOK_SECRET: the signing secret.

Secrets are masked in logs, which keeps the signing key out of your build output.

Step 3: Sign and send the request

Add this workflow as .github/workflows/deploy.yml. The deploy job waits for test, so a failed test never reaches production. Replace the test step with your own.

name: Deploy to Hubfly space
on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "run your tests here"

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Hubfly space deployment
        env:
          HUBFLY_WEBHOOK_URL: ${{ secrets.HUBFLY_WEBHOOK_URL }}
          HUBFLY_WEBHOOK_SECRET: ${{ secrets.HUBFLY_WEBHOOK_SECRET }}
          COMMIT_SHA: ${{ github.sha }}
        run: |
          body=$(printf '{"action":"pull","ref":"main","commitSha":"%s"}' "$COMMIT_SHA")
          timestamp=$(date +%s)
          signature=$(printf '%s.%s' "$timestamp" "$body" \
            | openssl dgst -sha256 -hmac "$HUBFLY_WEBHOOK_SECRET" -hex | sed 's/^.* //')
          curl --fail-with-body -X POST "$HUBFLY_WEBHOOK_URL" \
            -H 'Content-Type: application/json' \
            -H "X-Hub-Timestamp: $timestamp" \
            -H "X-Hub-Signature-256: sha256=$signature" \
            --data-binary "$body"

What each line does, in plain words:

body is the exact JSON you send. For a Git-backed container it names the branch and commit. For an image-based container, send {"action":"pull","image":"ghcr.io/your-org/your-app:sha-7f3b1a9"} instead.
timestamp is the current Unix time. It's part of the signature, which is what stops old requests from being replayed.
signature is an HMAC-SHA256 of timestamp.body, with the dot. Hubfly space computes the same value with your secret and compares.
--data-binary sends the body byte for byte. Change a single space after signing and the signature no longer matches.
--fail-with-body makes the job fail, and print the reason, if Hubfly space refuses the call.

On a self-hosted runner, keep in mind that openssl -hmac puts the secret on the command line, where other users on that machine could see it in the process list. Use a dedicated runner user.

For a project-scoped webhook, add "containerId":"<your container ID>" to the body.

Deploy an immutable tag (sha-7f3b1a9) or a commit SHA rather than latest. Then you always know which build is running, and a rollback has something specific to go back to.

Step 4: Watch it, and roll back when needed

Each call shows up under Pipeline → Recent deployments with its action, trigger, status, duration and any error. The webhook card counts Triggers and shows the Last Run. You can also list the history with GET /api/v1/projects/<project-id>/deployments.

If a release is bad, send the rollback action with the same signing step:

body='{"action":"rollback"}'

Rollback is an explicit action: send it yourself, from a manual workflow or an incident script. When you send an update, the docs also list rollback options for it: rollback.enabled, rollback.onHealthCheckFail and a positive rollback.timeoutSeconds, meant to revert the update if the new version fails its health check. A rollback needs a previous version to go back to, and a health-check trigger needs a health check, so always open the deployment event to confirm what actually happened.

What can go wrong

You see	Why	Fix
`401`	Wrong or missing URL token (Basic/Standard)	Copy the full URL again. Never add a token to a secure URL.
`400` on a secure webhook	Bad signature, a timestamp older than five minutes, or the body changed after signing	Sign `timestamp.body` and send the same bytes with `--data-binary`. Check the runner's clock.
`403`	The action isn't allowed, or the caller's IP isn't on the allowlist	Create a new webhook with the right actions or IPs.
"Container is missing"	Project-scoped webhook called without `containerId`	Add `containerId` to the body.
Image pushed, nothing changed	A registry push never redeploys by itself	Call the webhook with `{"action":"pull"}`.

Limits and pricing

Webhooks are free. There's no charge per webhook or per call.
The container is what you pay for. The shared tier (0.3 vCPU, 256 MB) is free for 360 runtime hours a month and sleeps when idle. A dedicated container with 1 vCPU and 512 MB running all month costs 1 × $0.004 × 730 + 0.5 × $0.002 × 730 = $2.92 + $0.73 = $3.65 a month.
Five-minute window for secure signatures.
One action per request, and only the actions you allowed when you created the webhook.
No edits: to change a webhook's mode, actions or IPs, create a new one and delete the old one.

Who this is not for

Teams on GitHub-hosted runners who want an IP allowlist. Those runners don't have fixed addresses, so the allowlist only fits self-hosted runners or a fixed-IP build server. Use the signature alone, or move the deploy job to a self-hosted runner.
Anyone who wants Hubfly space to build and deploy on every push with no CI at all. Connect the repo directly instead: Git deploys can deploy on push, or after CI succeeds.
Teams that want automatic rollback without health checks. Automatic rollback on an update depends on a health check (rollback.onHealthCheckFail). Add one first.
Pipelines that need preview environments per pull request. A webhook deploys to existing containers; it doesn't create a new environment for each branch.

Go further on Hubfly space

Add a health check so a failing release can be caught and rolled back: see the observability docs.
Send 10% of traffic to the new version first with a weighted load balancer: load balancer docs.
Get notified when an image is pushed or scanned with registry webhooks: webhooks docs.

Ready to stop redeploying by hand? No card needed: Start free, 360 hours included →

How to sandbox AI agents safely: one container per task

octave Nkurunziza — Wed, 21 Oct 2026 12:17:03 +0000

Originally published on the Hubfly space blog.

Updated 21 October 2026.

TL;DR

What you get: a fresh, locked-down container for every agent task, a budget with alerts for all agent work, an optional wallet and key per agent, and an off switch you can reach in two clicks.

Who it's for: developers letting an AI agent run code it wrote (coding agents, data agents, tool-using bots).

Time: about 15 minutes in the dashboard. The free shared tier gives you 360 compute hours a month.

Your agent writes a Python script and runs it. Most days that's fine. Then one day it deletes the wrong folder, prints your API keys into a log, or loops for six hours on a paid machine. If that code ran on your laptop or your main server, the damage lands on everything you own.

In this guide you'll give every agent task its own small, locked-down container on Hubfly space, put a budget around all of it, and set up a way to stop everything at once. The goal: when an agent does something dumb, only a throwaway box is hurt, the bill stays small, and you can switch it off in seconds.

Try it on Hubfly space. Steps 1 to 4 and 7 work on the free shared tier. Sub-account wallets (Step 5) need paid balance.

The safety model: four walls around every agent

Many sandbox guides cover containers, resource limits and network rules. Fewer cover spend limits, revocable keys per agent, or cleaning up what the agent leaves behind. A safe setup has four walls:

Wall	What it protects against	Where you set it
1. One container per task	A bad task breaking other tasks or your own machine	Create Container
2. Fewer Linux permissions	Code escaping its box or sniffing the network	Security Capabilities
3. Money limits	Surprise bills (alerts at 80% and 100%, per-agent wallets)	Project budget, sub-account wallet
4. An off switch and cleanup	Leftover containers and leaked keys	Danger Zone, key revoke

Build them in order.

Step 1: Create a project just for agent work, with a $10 budget

A Hubfly space Cell project holds containers, volumes, environment variables and a budget. Keeping agent work in its own project keeps its private network, its secrets and its bill apart from your real apps.

In the dashboard, click Create Project.
Name it agent-sandbox, pick Cell, and choose the region closest to you (for example eu-central).
Open Advanced Options and click the $10 quick cap under Monthly Budget Limit.
Click Create Project.

Why the budget? Agents don't get tired. A loop that keeps starting containers keeps going until something stops it. The project's Settings → General & Budget page shows your projected cost against the cap, and you get a notification at 80% and at 100%. Treat it as an alarm, not a guaranteed stop: Step 7 is how you actually stop things.

Step 2: Give each task its own container

Every task the agent runs gets a fresh container. When the task ends, you delete it. Nothing carries over, so a broken or poisoned task can't affect the next one.

In the project, click Create → Create Container.
Container name: agent-task-001. Use one name per task.
Deployment Source: Docker image. Use an image that contains your task runner, for example ghcr.io/your-org/agent-runner:1.0, or a plain runtime like python:3.12-alpine.
Resources: choose Shared Tier. It gives the task 0.3 vCPU, 256 MB of RAM and a small disk. That's a natural size limit: a runaway script can't eat a whole server.
Configuration → Process Settings → Command: the command the task runs, one argument per line. For a one-shot script:

python
/task/run.py

Avoid commands that serve files or open ports (like python -m http.server). Anything listening is reachable by every other container in the project.

Containers in the same project share a private network. If you run untrusted tasks side by side, run them one at a time per project, or give each agent its own sub-account (Step 5).

Step 3: Take away permissions the task doesn't need

Linux "capabilities" are small pieces of root power: changing file owners, opening raw network sockets, creating device files. A script that reads a CSV needs almost none of them. About half of the top sandbox guides skip this wall.

Go to Configuration → Security Capabilities. Two protections are already on by default:

Seccomp profile: runtime-default blocks dangerous system calls.
No new privileges: Enabled stops a process from gaining more power than it started with, even through a setuid program.

Below that, the container starts with 13 default capabilities. Under Drop capabilities, click these five:

Capability	What it allows	Why an agent task doesn't need it
`NET_RAW`	Raw sockets (ping, packet sniffing, spoofing)	Normal HTTP calls work without it
`MKNOD`	Creating device files	Ordinary scripts never create devices
`SYS_CHROOT`	Changing the root folder	A common step in escape tricks
`SETFCAP`	Giving capabilities to files	Lets a program grant itself power later
`SETPCAP`	Changing a process's capabilities	Same risk, at the process level

The Selection Summary now reads Added 8, Dropped 5.

Keep CHOWN, SETUID, SETGID and DAC_OVERRIDE unless you know your image never switches users or fixes file ownership at start-up. Many official images do, and they fail to start without them. Tighten one capability at a time and watch the logs.

Click Continue to Storage and add nothing. With no volume, the dashboard says "Ephemeral container storage will be used", so nothing the task writes survives it. Then Review and Deploy Container.

Step 4: Keep the sandbox off the internet

Don't add a domain or a public port to a task container. Without one, nobody outside can reach it. The Review step shows its private address, like agent-task-001-<id>.eucentral.hubfly.internal, and the private network is isolated to containers inside the same project.

Two limits to plan around:

Assume outbound traffic is open. Hubfly space doesn't document outbound (egress) controls, so assume the task can call any website. Never put secrets in a task container's environment. Give it only the one short-lived value it needs, or none.
Anything public gets found fast. A new public subdomain can see bot requests within minutes. If an agent must show a preview, put a login in front of it first.

Step 5: Give each agent its own wallet and key

So far, every agent works inside your account. If an agent holds a key to your account and that key leaks, all your projects are exposed. Hubfly space sub-accounts fix that: each agent becomes a separate tenant with its own projects, its own wallet and its own API keys.

Open your profile, then Sub-accounts → Create. Give it a name like research-agent and, optionally, an external reference.
In Manage, use Fund wallet to move a small amount (say $5) from your paid balance. Only paid balance can move, not promotional credit.
Click New key. The secret is shown once, so store it in your orchestrator's secret manager right away. Tenant keys start with hfsk_ and only work for that one tenant.
Give the agent its own agent-sandbox project inside the sub-account, and repeat Steps 2 to 4 there.

What you get:

Separate money. The agent's work is paid from its own wallet, which holds only what you moved into it.
A key you can kill. Revoke one agent's key without touching anything else.
Limits: 25 active sub-accounts and 10 active keys each by default, one level deep.

Careful: Revoke and Suspend act immediately, with no confirmation dialog. And suspending a sub-account doesn't stop its running containers, so stop or delete them first (Step 7).

Step 6: Automate it: create and remove a container per task

Clicking through the dashboard for every task doesn't scale. Your orchestrator (the code that hands tasks to the agent) can do Steps 2 and 3 with two API calls: create before the task, remove after. Field names follow the containers API reference. Check the resources units there before you rely on the values below, which mirror the shared tier.

# Run on your orchestrator, never inside the sandbox.
# HUBFLY_TOKEN: a key for the account that owns PROJECT
# (for a sub-account agent: its hfsk_ key and a project inside that sub-account).
API=https://api.hubfly.space/api/v1
PROJECT=<your-project-id>
TASK=agent-task-$(date +%s)

curl -sS -X POST "$API/projects/$PROJECT/containers/create" \
  -H "Authorization: Bearer $HUBFLY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "'"$TASK"'",
    "kind": "job",
    "tier": "shared",
    "source": { "type": "docker", "dockerImage": "ghcr.io/your-org/agent-runner:1.0" },
    "resources": { "cpu": 0.3, "ram": 256, "storage": 2 },
    "security": {
      "noNewPrivileges": true,
      "seccompProfile": "runtime-default",
      "dropCapabilities": ["NET_RAW", "MKNOD", "SYS_CHROOT", "SETFCAP", "SETPCAP"]
    }
  }'

Bake the task command into the image (CMD ["python", "/task/run.py"]), so the API call doesn't need it. When the task is done, remove the container. This is permanent:

curl -sS -X DELETE \
  "$API/projects/$PROJECT/containers/<container-id>/remove" \
  -H "Authorization: Bearer $HUBFLY_TOKEN"

Run the remove call in a finally block or an exit trap, so it also runs when the task crashes. Forgotten containers are a common way sandbox bills creep up.

Step 7: Your off switch

Know where this is before you need it. Open the project's Settings → Danger Zone (for a sub-account agent, the project inside its sub-account):

Hibernate Project removes running containers and networking routes but keeps the configuration, so you can restore later. Use it when an agent misbehaves and you want to look before you delete.
Delete All Resources permanently removes every container, volume and public route. The project itself stays.

If the agent has its own sub-account, open it next and Revoke its key. Hibernate already stopped what was running; the revoked key means the agent can't start anything new.

What can go wrong

1. "Monthly free tier compute hours exhausted. Upgrade this container to a dedicated tier to resume running."
The account has used its 360 free shared-tier hours for the month. Stop containers you don't need, or pick Dedicated Tier for task containers. A dedicated 1 vCPU / 512 MB container costs $0.005 an hour, so a 10-minute task costs less than a tenth of a cent.

2. The container exits right away after you dropped capabilities.
The image needed one of them, usually to switch users or fix file ownership at start-up. Open Logs, look for "operation not permitted", and add back only that capability (often SETUID/SETGID or CHOWN).

3. You suspended an agent and it's still costing money.
Suspend blocks the agent's keys and changes, but doesn't stop running containers. Stop or delete them first, then suspend.

What it costs

Rates: $0.004 per vCPU-hour and $0.002 per GB-hour of RAM.

Shared tier tasks: free within 360 compute hours a month.
A 10-minute task on a dedicated 1 vCPU / 512 MB container: (1 × $0.004 + 0.5 × $0.002) × 10/60 = $0.00083. A thousand of them is about $0.83.
One always-on dedicated worker (1 vCPU / 512 MB, 730 hours): 1 × 0.004 × 730 + 0.5 × 0.002 × 730 = $3.65 a month.

The dashboard says shared containers suspend after 15 minutes of inactivity. Don't count on it to clean up: delete task containers yourself.

Takeaway

An agent sandbox isn't one setting. It's four walls: a fresh container per task, fewer Linux permissions, money limits, and an off switch you've already found. Set them up once, and a bad agent run costs you a throwaway container and a few cents.

Go further on Hubfly space

Let your coding agent deploy without deleting your data: 1 skill, 3 permission lists.
One wallet and one key per customer, through the API: isolated SaaS tenants with sub-accounts.
Keep task results: write outputs to Hubfly space Storage (S3-compatible) instead of the container, which is deleted after the task. Storage docs.

Deploy this

Create your agent sandbox project on Hubfly space: free shared tier with 360 compute hours a month.

How to move your app from Railway to Hubfly space, step by step

octave Nkurunziza — Wed, 21 Oct 2026 06:35:05 +0000

Originally published on the Hubfly space blog.

TL;DR

What you get: your Railway web service and Postgres database running on Hubfly space, your data copied with one throwaway job, and your domain switched over with minutes of read-only time, not hours of downtime.

Who it's for: anyone with a Railway project made of a web service, a Postgres database and maybe a volume or a cron job.

Time needed: about 45 minutes for a small app, most of it waiting for DNS.

Cost on Hubfly space: about $7.31 a month for a web service and Postgres, each on 1 vCPU and 512 MB, running 24/7, plus 1 GB of disk. The math is below.

Your app runs on Railway and it works. But the bill moves with your traffic, and Railway's railway.json and railway.toml files stop working on 1 December 2026 (Railway docs). If you use config-as-code, you'll have to rewrite it either way. That makes now a good moment to decide where the app should live.

This guide moves a typical Railway project (a web service plus Postgres) to Hubfly space. You'll export your variables, describe the app in one Compose file, copy the database with a one-shot job that runs inside your new project, and switch your domain with a short write freeze. Your users see a few minutes of read-only mode at most, and you can roll back by pointing DNS back at Railway.

Try it on Hubfly space: the free tier includes 360 compute hours a month and needs no card, so you can rehearse the whole move before you pay anything.

Before you start: what moves, and where it goes

Write down every piece of your Railway project first. Anything you forget here becomes an outage later.

On Railway	On Hubfly space	How it moves
Service built from GitHub	Container built from the same repo, or a Compose service	Connect the repo or point Compose at an image
Postgres database service	`postgres:16-alpine` container with a volume	`pg_dump` piped into `pg_restore` (step 4)
Variables, including `${{Postgres.DATABASE_URL}}` references	Compose `environment:` or project variables, with `{{service:db.host}}` references	Export, then rewrite references (step 1)
Volume (one per service)	Volume mounted at the same path	Archive and upload (step 5)
Private hostname `web.railway.internal`	`{{service:web.host}}`	Replace in variables
Custom domain (CNAME + TXT)	Add the domain to the container	DNS switch (step 6)
`cronSchedule` service	A job container or an always-on worker	Re-create

Step 1: Export your variables

Variables are the easiest thing to lose. Export them per service with the Railway CLI (CLI reference):

railway link                      # pick the project and environment
railway variables --service web --kv > web.env
railway variables --service Postgres --kv > postgres.env

Open web.env and check three things:

Sealed variables are missing. Railway never shows sealed values in the UI, the API or the CLI (Railway docs). Find them in your password manager or your provider's console (Stripe, Resend, OAuth apps) and add them by hand.
Railway-only variables can go. Drop RAILWAY_* entries. Keep PORT only if your app reads it.
Database URLs point at Railway. The exported DATABASE_URL holds Railway's private hostname, which won't resolve anywhere else. You'll replace it in step 3.

Why this matters: a missing secret doesn't fail the deploy. It fails the first checkout or login after you switch DNS, in front of real users.

Step 2: Create the project

In the Hubfly space dashboard, click Create Project.
Name it after your app (orders-api), choose Cell, and pick the region closest to your users (eu-central, eu-north or usa-central).
Open Advanced Options and set a Monthly Budget Limit. $10 is plenty for the rehearsal. It keeps a mistake from turning into a surprise bill.
Optional: add shared values (an API key every service needs) under Project Environment Variables. They're encrypted with AES-256-GCM and are shared across the project.

Step 3: Describe the app in one Compose file

Railway builds each service separately. On Hubfly space you describe the whole app in one Compose file, and the Stack Composer deploys it in order.

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

  migrate:
    image: postgres:16-alpine
    restart: "no"
    environment:
      SOURCE_URL: <your Railway DATABASE_PUBLIC_URL>
      TARGET_URL: postgresql://postgres:change-me-long-random@{{service:db.host}}:5432/app
    command: ["sh", "-c", "until pg_isready -d \"$SOURCE_URL\" && pg_isready -d \"$TARGET_URL\"; do echo waiting; sleep 2; done; pg_dump \"$SOURCE_URL\" --format=custom --no-owner --no-acl | pg_restore --no-owner --no-acl --exit-on-error -d \"$TARGET_URL\" && psql \"$TARGET_URL\" -t -c 'SELECT count(*) FROM orders'"]
    depends_on:
      db:
        condition: service_healthy

volumes:
  pgdata: {}

What each part does:

db is your new Postgres. The named volume keeps its files across redeploys; without it, every update would wipe your data.
The health check uses -h 127.0.0.1. That forces a TCP check. Postgres briefly runs a temporary server on its Unix socket during first start, and a socket-only check can pass before the real server listens.
migrate is a one-shot job (restart: "no" becomes a Job). It waits until both databases answer, streams a dump from Railway straight into the new database, and prints a row count you can compare. No laptop in the middle, no dump file to store.
{{service:db.host}} is Hubfly space's version of Railway's ${{Postgres.DATABASE_URL}}. It resolves to the database's private hostname, inside a longer URL too.
Replace orders in the last command with one of your own tables.

Add your web service under services: the same way, with depends_on: db: condition: service_healthy and DATABASE_URL: postgresql://postgres:change-me-long-random@{{service:db.host}}:5432/app. If you'd rather build from GitHub than from an image, create the web container from your repo after the stack is up; a root Dockerfile wins over auto-detection.

Don't commit the real password. After the first deploy, open each container's Configuration → Environment Variables → Edit and switch the database variables, including SOURCE_URL, to Secret. Variables are edited one at a time there, so paste longer lists into the Compose file before you import it.

Step 4: Copy the database

First, give the copy job a way in. In Railway, open your Postgres service, enable public access through the TCP Proxy, and copy the DATABASE_PUBLIC_URL it creates (Railway Postgres docs). Paste it as SOURCE_URL.

Then rehearse:

In your project, click Create → Compose Stack, open the YAML tab, paste the file and click Import YAML.
Click Deploy Stack. The activity log shows the volume, then db, then the health gate, then migrate. A two-service stack like this one finishes in about 40 seconds.
Open the migrate container → Logs. You should see accepting connections for both databases, then your row count.

How long the real copy takes depends on bandwidth, not Postgres. Inside one region, a 24 MB database with 200,000 rows copies in about 2 seconds. Across the internet from Railway, the job's speed is set by the container's network link: a shared-tier container shows a 15 Mbps limit under its Network tab, roughly 2 MB per second. Custom-format dumps are compressed, so at 15 Mbps a 1 GB dump takes at most about 9 minutes. Run the rehearsal to get your real number. The job only runs for minutes, so the shared tier fits it. Railway bills proxy traffic as egress at $0.05 per GB (Railway pricing), so a 1 GB copy costs about 5 cents there.

Why rehearse: the dry run tells you exactly how long your write freeze will be, and it catches extensions or roles your new database is missing while nothing is at stake.

Step 5: Move volume files (skip if you only use Postgres)

Railway allows one volume per service. If yours holds uploads or a SQLite file, download the files with railway volume files or over scp through railway ssh (Railway volume docs). Then mount a volume at the same path on Hubfly space and copy the files into it, for example from a one-shot job that downloads the archive.

If those files are user uploads, consider moving them to Hubfly space Storage instead. It's S3-compatible, so your app's S3 client works with a new endpoint and keys, and it costs about $0.011 per GB-month.

Step 6: Switch the domain with a short write freeze

A day before: lower your domain's DNS TTL to 60–300 seconds, so the switch spreads in minutes.
Add the domain on Hubfly space: add app.your-domain.com to your web container, create the DNS records Hubfly space shows you, and wait for the certificate to be issued. Let's Encrypt issues and renews it for you.
Freeze writes on Railway: put the app in maintenance mode, or stop the web service. Anything written after the final dump would be lost.
Run the final copy into a clean database: open Project Settings → Danger Zone → Delete All Resources (the Delete Everything button) to remove the rehearsal containers and volume, then import and deploy the same Compose file again. Compare the job's row count with Railway's, then turn off public access (the TCP Proxy) on Railway's Postgres.
Switch DNS to the Hubfly space target and watch the web container's logs for real traffic.
Clean up later: keep Railway running read-only for a few days as your rollback, then delete its CNAME and TXT records (both are required on Railway) and the Railway services.

Rollback is simple while Railway still exists: point DNS back. Plan to roll back only before new writes land on Hubfly space; after that, copying new data back is a second migration.

What it costs: Railway vs Hubfly space

Prices as of 20 October 2026. Railway bills measured usage per second (railway.com/pricing); Hubfly space bills the size you reserve per hour (hubfly.space/pricing).

Setup (web + Postgres, 730 h, 1 GB volume)	Railway Hobby	Hubfly space
Light use: 0.15 vCPU and 0.45 GB RAM in use on average	$7.77 (the $5 plan fee is absorbed into usage)	$7.31 (two 1 vCPU / 512 MB containers, 24/7)
Busy: both services using 1 vCPU and 0.5 GB nonstop	$50.88	$7.31 (same reserved size)
Staging copy that sleeps most of the day	Pays for active time; a slept service accrues no compute charges (docs)	Shared tier, free within 360 compute hours a month

Railway math (CPU $0.00000772 per vCPU-second, RAM $0.00000386 per GB-second, volume $0.00000006 per GB-second; 730 h = 2,628,000 s):

Light: 0.15 × 0.00000772 × 2,628,000 = $3.04; 0.45 × 0.00000386 × 2,628,000 = $4.56; 1 × 0.00000006 × 2,628,000 = $0.16. Total $7.77.
Busy: 2 × 0.00000772 × 2,628,000 = $40.58; 1 × 0.00000386 × 2,628,000 = $10.14; volume $0.16. Total $50.88.

Hubfly space math (CPU $0.004 per vCPU-hour, RAM $0.002 per GB-hour, storage $0.00001536 per GB-hour):

One container: 1 × 0.004 × 730 = $2.92; 0.5 × 0.002 × 730 = $0.73. That's $3.65.
Two containers: $7.30. Volume: 1 × 0.00001536 × 730 = $0.011. Total $7.31. Faster volume modes (Balanced 1.5×, High Performance 2×) add up to about a cent per GB a month ($0.017 and $0.022 instead of $0.011).

The honest read: for a small, quiet app the two bills land within a few cents of each other. Hubfly space wins when your app does steady work, because the price doesn't climb with load. Railway wins when your services idle near zero most of the month.

Where Railway is still the better pick

Fair is fair. Stay on Railway, or move only part of your app, if you depend on:

PR environments: Railway spins up an isolated copy of your environment for every pull request and deletes it when the PR is merged or closed (docs).
Built-in database backups and point-in-time restore, plus in-place Postgres major-version upgrades with automatic backups and one-click revert (docs). Hubfly space doesn't document database backups yet, so schedule your own pg_dump to Storage if you move.
Paying almost nothing for idle services: with per-second usage billing, a mostly idle app can cost less than a reserved container.
More regions and multi-region replicas: Railway lists four regions across the US, Europe and Asia (regions) and can place replicas in several of them (scaling). Hubfly space offers three regions today.

What can go wrong

no response or Name does not resolve on the first connection. A fresh container can take a couple of seconds before private DNS answers. The until pg_isready …; do sleep 2; done loop in the job handles it. Without the loop, the job fails, the stack rolls back, and the job's logs go with it.
The health check passes too early. pg_isready without -h 127.0.0.1 can succeed against Postgres's temporary startup server. Keep the -h 127.0.0.1 flag so dependents wait for the real one.
${{...}} or $$ copied as-is. Railway's ${{Postgres.DATABASE_URL}} means nothing elsewhere; replace it with a full URL using {{service:db.host}}. And write $VAR in Compose commands, not $$VAR: the Stack Composer keeps $$ literally, and the shell turns it into a process ID.

Takeaway

A Railway move is mostly bookkeeping: export the variables, rewrite the references, copy the data with a job that runs next to the new database, and switch DNS during a short freeze. Rehearse once on the free tier and the real cutover is a few minutes of read-only mode.

Read next:

Go further on Hubfly space

Put uploads in Hubfly space Storage: S3-compatible buckets with image resizing built in (docs).
Reach the database from your laptop without opening it to the internet, with a HubTunnel from the Hubfly space CLI (tunnels docs).
Deploy automatically on every push with deploy webhooks and auto-rollback (deployment pipelines).

Ready to move? Create a free Hubfly space project, paste the Compose file above, and run your first rehearsal copy today. Moving a bigger Railway project? Talk to us about help with the cutover.

How to resize and watermark product photos with just a URL

octave Nkurunziza — Mon, 19 Oct 2026 16:32:55 +0000

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: transforms are free. You pay only for storing originals and cached variants, at the Standard storage rate of about $0.011 per GB-month.

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.

Parameter	What it does	Limits
`w`, `h`	Output width and height	1–4,096 px each, 16 megapixels max
`fit`	`inside` (default), `contain`, `cover`, `fill`	Anything except `inside` needs both `w` and `h`
`format`, `quality`	`webp` (default), `jpeg`, `png`; quality 1–100 (default 80)
`fx`, `fy`	Focal point for `cover` crops, 0 to 1	Defaults to the centre
`rotate`, `flip`	0/90/180/270; `h`, `v` or `hv`
`blur`, `sharpen`, `brightness`, `contrast`, `saturation`	Effects	Service-side bounds
`wm_text` or `wm_key`	One text or image watermark, placed with `wm_x`, `wm_y`, `wm_opacity`	Image watermarks must be saved as allowed first

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/:

Step	Route	Key fields
Get a short-lived upload URL	`POST objects/upload-session`	`bucket`, `objectKey`, `contentType` → `upload_url`, `expires_at`
Upload the bytes	`PUT` to `upload_url`	before `expires_at`
Register the asset	`POST assets/create`	`bucket`, `objectKey`, `title` → asset ID and URL
Make it public	`PUT assets/update`	`assetId`, `accessMode: "public"`
Share a private file	`POST assets/share-token`	`assetId`, `ttlSeconds`

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

What can go wrong

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.
"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.
"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: free. 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 you can follow it under Activity & usage in the dashboard.
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.

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 →

Best Heroku alternatives in 2026: 7 options and what they cost

octave Nkurunziza — Mon, 19 Oct 2026 14:36:24 +0000

Originally published on the Hubfly blog.

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)

Platform	Web service (512 MB)	Postgres	Monthly total	Database is
Heroku	Basic dyno $7	Essential-0, 1 GB $5	$12	Managed
Render	512 MB instance $7	256 MB RAM, 1 GB SSD $6	$13	Managed
DigitalOcean App Platform	1 vCPU, 512 MiB $5	Dev database, 512 MiB $7	$12	Managed (dev tier)
Railway	0.5 GB RAM, usage-based (rates)	Same, plus 1 GB volume	about $12.33 (see math, quiet app)	You run the template
Fly.io	shared-cpu-1x, 512 MB $3.69	Same machine size + 1 GB volume ($3.69 + $0.15)	$7.53	You run it
Fly.io + Managed Postgres	$3.69	Basic $38 + 1 GB at $0.28	$41.97	Managed
Hubfly space	1 vCPU, 512 MB, always on: $3.71	Same size + 1 GB volume: $3.72	$7.43 (see math)	You run it
Koyeb	eco-micro, 0.25 vCPU, 512 MB $2.68	small, 1 GB RAM $29.76 + 1 GB at $0.50	$32.94	Managed
Coolify on Hetzner CX23	One server, 2 vCPU, 4 GB: $6.49 excl. IPv4	Runs on the same server	$6.49 + IPv4	You run it, and the server

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

Platform	Free web service	Free database	The catch
Heroku	None. Eco is $5	None	Eco dynos sleep after 30 minutes of inactivity
Render	Yes, 750 hours a month (docs)	Yes	Web spins down after 15 minutes without traffic and takes about a minute to wake. Free Postgres expires after 30 days, with a 14-day grace period
Railway	30-day trial with $5 credit, then $1 a month (pricing)	Within credit	0.5 GB RAM per service and 0.5 GB of volume on Free
Fly.io	Trial only: 2 hours of machine time or 7 days (pricing)	No	Pay as you go after that
DigitalOcean	Static sites only, up to 3 apps (pricing)	No	No free container
Koyeb	1 web service, Frankfurt or Washington (instances)	1 database, 5 hours of active time, 1 GB (FAQ)	Free instance scales to zero after 1 hour without traffic
Hubfly space	Shared tier, 360 compute hours a month, no card (pricing)	Postgres runs as a container on the same free hours	Shared containers sleep when idle. Volumes are still billed (1 GB is about $0.02 a month)

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).

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.

Docker health checks that catch real problems, explained simply

octave Nkurunziza — Mon, 19 Oct 2026 09:20:03 +0000

A plain guide to Docker health checks for your app, Postgres (pg_isready) and Redis, and three mistakes that make a check pass when it shouldn't.

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:

Setting	What it means	Docker default
`interval`	How often the check runs	30s
`timeout`	How long one run may take before it counts as failed	30s
`retries`	Failures in a row before "unhealthy"	3
`start_period`	Grace time after start when failures don't count	0s

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

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.
In the project, click Create → Compose Stack, open the YAML tab, paste the full file below, and click Import YAML.
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.

Deploy a docker-compose.yml as-is: 8 platforms, which keys survive, and what web + Postgres + Redis costs

octave Nkurunziza — Sun, 18 Oct 2026 16:14:13 +0000

Originally published on the Hubfly blog.

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.

Platform	Compose support	How	What the docs say about keys
Coolify (self-hosted)	Yes, native	Git repo or "Raw" mode	`build:`, named volumes, healthchecks supported; bind mounts only inside the resource folder; avoid `ports:` (docs)
Hubfly	Yes, native	Paste or upload YAML in the Stack Composer	Walkthrough below: `depends_on` conditions, healthchecks, named volumes, `command`, `ports` kept; bind mount dropped
Railway	Yes, import	Drag the file onto the project canvas	Railway says it doesn't support every Compose config yet; per-key list not published (docs)
Fly.io	Early	`[build.compose]` in `fly.toml`	Announced in a community post (July 2025), not in the main docs; many features listed as incompatible (post)
Render	No	Rewrite as a `render.yaml` Blueprint	Compose isn't in the Blueprint spec; the feature request dates from 2019
DigitalOcean App Platform	No	App spec, from Git or images	Compose not listed (support page)
Koyeb	Workaround	Docker-in-Docker in one privileged service	Official tutorial uses the Privileged toggle; no native import
Heroku	No	Git or Docker deploys	Compose isn't offered on the pricing page

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.

Import. Create → Compose Stack → YAML tab → paste → Import YAML. It loaded in under a second.
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.
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).
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.

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.

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.

Platform	Web	Postgres	Redis	Monthly total	Managed DB?	Pricing page
Coolify + Hetzner CX23	one box	on the box	on the box	$6.49 + IPv4 ($11.49 + IPv4 with Coolify Cloud)	No, you run it	Hetzner, Coolify
Hubfly (dedicated, always on)	$2.19	$2.19 + volume	$2.19 + volume	≈ $6.67	No, containers + volumes	Hubfly pricing, math below
Fly.io, self-run DBs	$3.69	$3.69 + $0.15 vol	$3.69 + $0.15 vol	$11.37 (+$2 for a dedicated IPv4)	No	Fly pricing
Heroku	$7 Basic	$5 Mini	$3 Mini	$15	Yes	Dynos, Postgres + Key-Value
Render	$7	$6	$10 Key Value	$23	Yes	Render pricing
DigitalOcean App Platform	$5	$7 Dev DB	$15 Valkey	$27 ($35.15 with a full managed Postgres)	Yes	App Platform, Valkey, Databases
Koyeb	$5.36 micro	$30.26 (Small $29.76 + 1 GB at $0.50)	$1.61 eco-nano, self-run	$37.23 (a plan fee may apply; check the pricing page)	Postgres yes	Instances, Postgres pricing
Railway	$15	$15 + $0.15 vol	$15 + $0.15 vol	up to ≈ $45.30	No, services you run	Plans
Fly.io, managed	$3.69	$38.28 MPG Basic	$10 Upstash fixed	$51.97	Yes	Fly pricing, Upstash on Fly

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

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.
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).
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

Create a Cell project with a $10 budget cap (Advanced Options at project creation).
Create → Compose Stack → YAML → paste the file above (change the password) → Import YAML.
Check the JSON tab to see what survived. Deploy Stack and watch the activity log.
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.

Isolated SaaS tenants on Hubfly: 1 wallet and 1 key per customer in 4 API calls

octave Nkurunziza — Sun, 18 Oct 2026 08:57:26 +0000

Originally published on the Hubfly blog.

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.

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.
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.

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.

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.

Per tenant, always on (730 h)	Math	Monthly
1 vCPU, 0.5 GB RAM, 5 GB disk	2.92 + 0.73 + 0.06	$3.71
0.5 vCPU, 0.5 GB RAM, 5 GB disk	1.46 + 0.73 + 0.06	$2.25
25 tenants on the first size	25 × $3.706	$92.65

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

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.
You suspend a tenant and it keeps billing. Suspension disables credentials and changes, not running containers. Stop the tenant's workloads first, then suspend.
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.
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.

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.

Canary releases with a weighted load balancer: 10% to v2, proven with 200 requests

octave Nkurunziza — Sun, 18 Oct 2026 08:56:13 +0000

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:

The strategy must actually read the weights. Some strategies ignore them.
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.
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.

Balancer name: canary-router.
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.
Ingress domains → Add Domain → Hubfly Free → Attach Free Domain. You get an HTTPS subdomain like canary-router-xx-xxx.eu1.hubfly.app.
Strategy: choose Weighted Round Robin. Not "Round Robin". This is the step the rest of this post is about.
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:

Strategy	Targets / weights	Requests	v1	v2	v2 share
Round Robin	app-v1 w9, app-v2 w1 (dashboard showed 90% / 10%)	200	78	122	61%
Round Robin, 2nd run	same	200	100	100	50%
Round Robin	3 × v1 + 1 × v2, all weight 1	200	150	50	25%
Weighted Round Robin	app-v1 w9, app-v2 w1	200	180	20	10%
Weighted IP Hash	app-v1 w9, app-v2 w1, one client	40	40	0	0%

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.

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.