The hidden cost of self-hosting a relay: what it costs per month in money and time

Software cost first: this one really is zero

One API, New API, LiteLLM and sub2api are all open source, so the software itself costs nothing. That line item genuinely is zero and needs no discount.

The problem is that it is a small part of the total.

Cost item one: server and network

A workable configuration:

Mind the server location. Reaching overseas models means the node must be outside the mainland, and a Singapore node can keep domestic latency under about 80ms. But if the gateway serves a team inside the mainland you also have to consider how stable the route to that node is, since some links wobble badly in the evening peak.

Subtotal: CNY 50 to 200 per month.

Cost item two: time, the most underestimated item

Based on what people who have actually done it report, the time to get a self-hosted gateway running stably breaks down as:

At CNY 200 an hour, a deliberately conservative developer rate, that is roughly CNY 1,200 to 2,600 in the first month and CNY 200 to 800 a month after that, excluding incidents.

The conclusion here matters: the cost of self-hosting is driven by ongoing maintenance, not by the initial deployment.

Cost item three: the hidden costs

Upgrade risk

One API has a record of version upgrades breaking the database schema. New API is better disciplined but still releases frequently. Backing up and validating a migration before each upgrade is itself standing work.

Security responsibility

Self-hosting puts all of this on your side:

• Key management: if an upstream key in the gateway leaks, the loss is yours
• Access control: who may use it, how much, and how limits are enforced
• Audit and traceability: being able to reconstruct what happened
• Log compliance: logs may contain request content, which raises retention and privacy questions

With someone else's relay site these responsibilities sit with them; self-hosted, they all sit with you. That is not something a cost figure fully expresses.

Single point of failure

If your own gateway goes down, everything goes down. Relay sites usually have multi-channel redundancy, so the dependency you see is also someone else's redundancy.

Solving this means building your own high availability, with multiple instances, health checks and automatic switching, which is another layer of work.

Below what scale you should not self-host

A practical line:

Only you use it: do not self-host. Take a platform key directly, or use an off-the-shelf relay site. The time saved far exceeds the money saved.

Two or three people, low volume, occasional manual intervention acceptable: self-host if you like, at the lowest possible cost. One light server plus SQLite, no high availability, the occasional manual restart accepted. The main benefit here is unified management, so nobody needs their own key, rather than saving money.

More than three people, the bill in one name, or keys already spread across platforms: you should self-host. The trigger is the classic pain point where one colleague blows through their key and everyone else's work stops. What self-hosting solves here is not a cost problem but a governance problem.

Reconciliation, quotas and audit requirements: you must self-host or use an enterprise-grade managed service. Off-the-shelf relay sites basically cannot meet these needs.

When self-hosting is clearly worth it

Three clear cases:

1. You already hold free credits on several platforms from trial allowances and need one exit to use them all. This is the best-value case, with zero marginal cost to put existing quota to work.
2. Several people on a team need one shared exit with per-person quota allocation.
3. There is a hard requirement on data flow, where requests must not pass through a third party, so you must close the path yourself.

A pragmatic middle path

If you sit between wanting unified management and not wanting the full operational burden, take two steps:

Step one: use an off-the-shelf relay site, but collapse every call in your code into one base_url variable and one config entry. Switching then costs almost nothing.

Step two: when team size or approval requirements arrive, point that base_url at your own gateway. Not one line of front-end code changes.

The benefit of this approach is that you do not pay operational cost today for a self-hosted gateway you may want later, and you are not locked into any single site.

Our selection articles keep returning to the same point: work out your own usage pattern first, then decide whether to introduce an infrastructure layer you maintain yourself.