A disposable API server
Nothing lives on it but code: rebuild, resize or move it in minutes with the same .env. Caddy gets its certificates again by itself.
API Maker
The backend engine for the AI era
Level 2 · GrowArchitecture 03 of 13
A stateless API server, with the MongoDB, logs and Redis of API Maker on servers of their own.
Everything API Maker keeps moves off the API server: definitions to its MongoDB, cache and events to Redis, logs to their own database. The API server becomes disposable, ready to be rebuilt in minutes or joined by others.
Every request is drawn as it travels. Slow it down, pause, go step by step, or open the full canvas and zoom in.
The API server keeps nothing. Definitions, cache, events and logs all live on the data tier. The API server only runs Caddy, API Maker under systemd and its sandboxes.
The same steps as the diagram, in more detail.
Everything API Maker remembers moves off the API server. What you build in the admin panel lives in API Maker DB, cached responses in one Redis, events and locks in another, logs in their own database. The API server runs code only: Caddy, API Maker with its admin panel under systemd, and the sandbox containers of custom code.
Instances, schemas, custom APIs, hooks, schedulers, users and roles are stored in API Maker DB, a MongoDB replica set. API Maker keeps them in memory, so serving a request needs no round trip to it. When something changes, an event goes through the internal Redis and every server reloads it.
redisInternal is what API Maker needs to work: events between the servers, the keys of the schedulers, WebSocket subscriptions and auto increment values. redisExternal holds cached responses of your APIs, capped by maxCharsResToCache and expired after redisValueExpireInSeconds. Apart, cache pressure never touches the rest.
API Maker logs every call: request, response, duration, errors and console output of custom code. With a logs database of its own, this write-heavy traffic never competes with your data. A daily scheduler keeps the newest maxLogsCount entries, and the log explorer of the admin panel searches them.
Because nothing lives on it, the API server can be replaced at any time: to recover from a failure, to move to another provider or to a bigger machine. Install API Maker on a fresh VPS with the same .env file and point the domains at it: systemd starts API Maker, Caddy gets its certificates again by itself, and every API is served at once. Nothing to restore, nothing to migrate.
Nothing lives on it but code: rebuild, resize or move it in minutes with the same .env. Caddy gets its certificates again by itself.
MongoDB gets fast disks, Redis gets memory, logs get room to grow: every server is sized for what it does.
Every call is logged to a database of its own and trimmed daily, without touching your data.
Responses live in their own Redis, so evicting cache never touches locks, events or WebSocket subscriptions.
A second API server with the same .env serves the same APIs at once. The next architectures do exactly that.
The apps only reach Caddy, on the API server. The data servers accept its private IP and nothing else.
On video
Design a cluster on a canvas: API Maker on several servers behind a gateway, databases clustered over the servers you pick, a MongoDB replica set, MariaDB as a Galera cluster, Caddy, Ferron or Pingap as reverse proxies with their own domains and Let's Encrypt certificates, and every rule checked before anything is deployed.
Every video of API MakerPlain VPS from any provider, or your own servers, with Ubuntu 24.04 LTS, installed by API Maker Launchpad. Sizes are a starting point: measure and adjust.
Runs
Ports
Runs
Ports
Three members make it highly available: see the High availability architecture.
Runs
Ports
Runs
Ports
am__serverName="api-1"# Definitions and logs: the MongoDB serveram__mongo_db_connection="mongodb://api_maker:***@10.0.0.20:27017/api_maker_db?authSource=admin&replicaSet=rs0"am__logs__mongo_db_connection_logs="mongodb://api_maker:***@10.0.0.20:27017/api_maker_logs?authSource=admin&replicaSet=rs0"am__logs__maxLogsCount="100000" # newest logs keptam__logs__logRemoveSchedulerInterval="0 0 0 * * *" # trimmed every day# Events and locks, and the cache: the Redis serveram__redisInternal='{"nodes": [{host: "10.0.0.30", port: 6379, pass: "***"}]}'am__redisExternal='{"nodes": [{host: "10.0.0.30", port: 6390, pass: "***"}], redisValueExpireInSeconds: 7200, maxCharsResToCache: 1000000}'The "Encrypt Strings" tool of the dashboard encrypts these connection strings before they go into .env.
Everything you build in the admin panel: instances and their encrypted connection strings, schemas, custom APIs, hooks, schedulers, WebSocket events, users, roles and settings. That is why any API Maker server that points to it serves the same APIs.
redisInternal carries what API Maker needs to work: events between the servers, the keys of the schedulers, WebSocket subscriptions and auto increment values. redisExternal holds the cached responses of your APIs, which can be evicted at any time. On small setups both can be the same Redis.
Yes. logs.enableLogs turns them off, logs.maxLogsCount sets how many of the newest logs are kept, and logs.logRemoveSchedulerInterval sets when older ones are removed, every day by default.