Deployment architectures
From one VPS to a global fleet
13 ways to run API Maker, from the simplest to the most dynamic. Each one uses only API Maker, run by systemd behind Caddy, your databases, MongoDB and Redis, on plain VPS from any provider or on your own servers. No managed cloud services, no lock-in.
- 1 to 25+ servers
- Any VPS provider
- 8 database types
- A live diagram for each
Level 1
Start
One or two servers. Live in minutes, every feature included.
Level 2
Grow
Separate tiers and a proper release flow, ready to add servers.
Level 3
Scale
Several API servers, real-time events everywhere, many customers.
Level 4
Resilient
Clusters and replicas: no single server can take you down.
Level 5
Global
Servers on several continents and clouds, near every user.
Compare them side by side
What each architecture gives you. They combine too: a multi-tenant platform can also be highly available and global.
| Architecture | Servers | Databases on their own servers | Add servers for more capacity | Survives the loss of a server | Several clouds or data centers | Serves users from near them | A database per customer or project | Estimated capacity |
|---|---|---|---|---|---|---|---|---|
| 01 All-in-one server | 1 VPS | No | No | No | No | No | No | ~7,423 req/s on 4 cores |
| 02 Separate database server | 2+ VPS | Yes | No | No | No | No | No | ~7,423 req/s on 4 cores |
| 03 Dedicated data tier | 4 VPS | Yes | No | No | No | No | No | ~7,423 req/s on 4 cores |
| 04 Environments with Git | 4+ environments | Yes | Yes | No | No | No | No | ~14,846 req/s on PROD, 2 × 4 cores |
| 05 Load-balanced API servers | 7+ VPS | Yes | Yes | No | No | No | No | ~33,006 req/s on 3 × 8 cores |
| 06 Real-time events across servers | 5+ VPS | Yes | Yes | No | No | No | No | ~22,269 req/s on 3 × 4 cores |
| 07 Many projects, one platform | 5+ VPS | Yes | Yes | No | No | No | Yes | ~18,426 req/s on 2 × 6 cores, shared |
| 08 Multi-tenant: a database per customer | 5+ VPS | Yes | Yes | No | No | No | Yes | ~14,846 req/s on 2 × 4 cores, shared |
| 09 Clustered Redis and databases | 13+ VPS | Yes | Yes | No | No | No | No | ~22,269 req/s on 3 × 4 cores |
| 10 High availability | 10+ VPS | Yes | Yes | Yes | No | No | No | ~22,269 req/s on 3 × 4 cores |
| 11 Multi-cloud | 12+ VPS | Yes | Yes | Yes | Yes | No | No | ~29,692 req/s on 4 × 4 cores |
| 12 Geo-routing: the nearest region | 10+ VPS | Yes | Yes | Yes | Yes | Yes | No | ~22,269 req/s on 3 regions × 4 cores |
| 13 Global enterprise platform | 25+ VPS | Yes | Yes | Yes | Yes | Yes | Yes | ~44,538 req/s on 6 × 4 cores |
Capacity is estimated from our benchmark on Linode servers with shared CPU (get all on MongoDB, 10 rows of 10 columns, the database on the same server): 2,435 req/s on 1 core and 11,002 req/s on 8 cores. With several API servers it is the result of one server times their number, which assumes the data tier keeps up: clusters were not load tested this way. Your numbers depend on your APIs, your data and your databases.
What every architecture has in common
Moving from one to the next is a matter of servers and connection strings, never of rewriting APIs.
Installed by API Maker Launchpad
Draw the architecture and Launchpad installs every server over SSH, on a plain Ubuntu VPS: API Maker under systemd, Caddy in front.
HTTPS and WSS by Caddy
Caddy receives every request first. It gets the certificates from Let's Encrypt and passes plain HTTP and WebSocket to API Maker, which has no TLS of its own.
systemd keeps it running
systemd runs API Maker, starts it at every boot and again if it stops. API Maker is one process, which uses every CPU core.
Apps reach Caddy only
Ports 80 and 443 of Caddy are all the apps reach. API Maker, MongoDB, Redis and your databases stay on the server or the private network.
The same APIs everywhere
APIs, schemas and settings live in API Maker's MongoDB, so every server serves all of them.
Redis ties the servers together
Cache, WebSocket subscriptions, events between servers and the keys of the schedulers go through Redis.
Git pull is deployment
Pull on one server and every server of the environment serves the new version as soon as the pull commits.
Shared secrets
passJWT, passDBEncryptDecrypt and passCommunication are the same on every server of a project.
One dashboard for the fleet
Traffic, latency, logs and Docker of every server in one place, with remote restarts.
Where should I start?
Pick the situation that sounds like yours.
Not sure which one fits?
Tell us about your traffic, your users and your data. We will help you pick and size your architecture.