How to Self-Host one-api / new-api: The Software Behind Most Relays
This is a technical explainer, not a guide to starting a relay business. The goal is to help you understand where the technical architecture behind most relays actually comes from — once you know the underlying logic, you'll read any relay's dashboard terminology and settings much faster.
Most relays are built on the same open-source project
The admin backends behind most relays out there weren't written from scratch — they're built on top of two open-source projects: one-api and new-api. one-api was one of the earlier, more influential projects in this space; new-api is an actively maintained fork of it with meaningfully expanded features and UI. Because so many providers share the same underlying logic, you'll notice that even though the branding, color scheme, and domain are completely different from one relay to the next, the core concepts and workflow are strikingly similar.
What these projects actually provide
Multi-channel aggregation
Connects multiple upstream sources at once — official APIs, discounted cloud channels, sliced subscriptions — and manages each as a separate "channel" in one dashboard.
User and token management
Issues separate API keys (tokens) per user, with configurable quotas and expiration, making it straightforward to run a multi-user operation.
Token-based billing
Automatically tracks input and output token usage per call and bills against a preset multiplier — this is literally where the term "billing multiplier" comes from.
Groups and multipliers
Different channels and models get organized into "groups," each with its own multiplier — which is exactly why the same model can be priced differently depending on which group you're in.
Redemption codes and referral rewards
Built-in tooling for generating redemption codes and referral incentives, making it easy for an operator to run promotions and grow their user base.
Why this matters even if you're not self-hosting
When you see "channel," "group," "multiplier," and "token" on a relay's dashboard, those are all terms baked into this open-source architecture — a channel is a single upstream source that's been connected, a group is a bucket of channels and models sharing an independent multiplier, and a token is your API key. Once you understand that structure, you'll get why the same model is priced differently across groups, and why so many relays' /api/pricing endpoints return data shaped almost identically — they were built on the same skeleton to begin with.
The real barriers to self-hosting
If you want to deploy one-api or new-api yourself, the technical setup itself isn't that hard — both projects ship with ready-to-follow deployment docs. What actually determines whether a relay can operate reliably is everything the open-source project doesn't solve for you: you need a stable upstream API source (an official key or some other reliable channel — the open-source project can't help with this part); you need to handle service reliability and abuse prevention (blocking malicious use and quota abuse); and if you're planning to serve other people, you'll need to wire up payments and handle support. The open-source project only solves the "admin dashboard" layer — sourcing supply and running operations, the two genuinely hard parts, are still on you.
Who this is for, and one thing to keep in mind
This content is most useful for two kinds of people: developers who want to self-host for personal or team use (say, centrally managing API keys for yourself or a few teammates), and anyone who just wants to understand how relays work and make sense of dashboard terminology. Worth flagging: if you plan to deploy this and sell access publicly, you'll run into business registration, payment compliance, and tax questions that are entirely on you to figure out — this article is a technical explainer only and isn't business advice.
FAQ
What's the relationship between one-api and new-api?
new-api is an actively maintained fork of one-api, adding UI and feature improvements on top of the original. A lot of newer relays choose new-api these days. The core architecture and concepts — channels, groups, multipliers, tokens — are shared between them.
Why do so many relay dashboards and API structures look nearly identical?
Because a lot of providers built on top of the same open-source project. Even after a full rebrand and UI customization, the underlying routing structure, terminology (channel, group, multiplier), and API conventions tend to stay consistent — which is why you'll notice endpoints like /api/pricing looking similar across completely unrelated providers.
If I self-host one-api or new-api myself, can I sell API access like a relay does?
Deploying it technically isn't hard, but that only solves the "admin dashboard" layer. You'd still need your own upstream API source (an official key or another reliable channel), you'd need to handle service reliability and abuse prevention, and you'd need to wire up payments and support. None of that comes with the open-source project — it's the actual hard part of running a relay business.
What's the point of understanding this architecture if I'm not going to self-host?
Knowing where terms like "channel," "group," "multiplier," and "token" come from means you can read any relay's dashboard faster and understand its billing logic and settings more quickly — and it makes it easier to judge whether a given provider is run competently and whether its pricing actually makes sense.