API Maker

The backend engine for the AI era

Level 1 · StartArchitecture 01 of 13

All-in-one server

API Maker, its MongoDB, Redis and your database on a single VPS.

The fastest way to production: one Ubuntu VPS from any provider runs everything. API Maker Launchpad sets it all up over SSH, with Caddy for HTTPS and systemd to keep API Maker running: every feature of API Maker, at the lowest possible cost.

Watch it live Server configuration

See it live

Every request is drawn as it travels. Slow it down, pause, go step by step, or open the full canvas and zoom in.

api-maker/architectures/single-serverLive
  • Request
  • Response
  • Cache hit
  • Write
  • WebSocket event
  • HTTPS and WSS up to Caddy
Servers
1VPS
Threads
4CPU cores
Capacity
~7,423req/s
Cache hits
0%of reads

Launchpad sets it up. API Maker Launchpad puts MongoDB, Redis, API Maker under systemd and Caddy on a fresh Ubuntu VPS, over SSH. Your database can live on the same server.

How it works

The same steps as the diagram, in more detail.

  1. Launchpad sets it up.

    Add a fresh Ubuntu VPS to API Maker Launchpad and deploy. Over SSH it installs Docker, starts MongoDB as a replica set and Redis in containers, then API Maker, one program which systemd runs as the service api_maker_be and starts again after every reboot. Caddy comes last: it gets the TLS certificates of your domains and stands in front of the APIs, the WebSockets and the admin panel. MongoDB runs as a replica set even on one server, because API Maker uses its transactions, e.g. to apply a Git pull all at once.

  2. Caddy answers HTTPS and WSS.

    API Maker has no TLS of its own: it answers plain HTTP and WebSocket on one port, 38246. Caddy, set up by API Maker Launchpad, listens on ports 443 and 80, gets free certificates for your domains from Let's Encrypt and renews them by itself. It passes api.example.com and ws.example.com to 127.0.0.1:38246, and admin.example.com to the admin panel, which API Maker serves on port 4626. The apps need nothing but ports 80 and 443.

  3. Every core serves requests.

    Web and mobile apps send their requests to https://api.example.com, and Caddy passes them to port 38246. API Maker is one process with as many threads as the server has cores, and the requests are shared between them. There are no worker processes to start, to size or to balance.

  4. Repeat reads skip the database.

    Turn on caching for a table, an API or a custom API and API Maker keeps the responses in Redis. The next same request is answered from memory, with the header x-am-data-source: cache. Every insert, update or delete through API Maker resets the cache of its table; a change made in the database directly shows once the key expires (redisValueExpireInSeconds).

  5. Changes are pushed live.

    Frontends and devices open a WebSocket to wss://ws.example.com: Caddy keeps it open and passes it to port 38246, the port of the APIs. They subscribe to events: calls of an API, like the insert of an order, with conditions on the response, or events of your own custom code. API Maker publishes the event in Redis when it answers the call, and the server holding the WebSocket pushes it to the client. No polling, no extra server.

  6. Custom code runs sandboxed.

    Business logic written in the admin panel (custom APIs, pre and post hooks, schedulers, utility classes), in TypeScript, Python, PHP, C#, Go, Rust, Java or Kotlin, runs in sandbox containers managed by API Maker, apart from its process: custom code never blocks the generated APIs and cannot reach the files of the server. A server has one sandbox by default, which every thread of the process uses.

  7. systemd keeps API Maker running.

    API Maker is set up as the systemd service api_maker_be and enabled, so it comes back after every reboot. If the process exits, systemd starts it again a second later. Its output goes to ~/logs/api_maker_be.txt, rotated past 50 MB. systemctl status and systemctl restart api_maker_be are the commands to know.

  8. Grow the server when you need to.

    More traffic? Resize the VPS: after a short restart, systemd starts API Maker again and its threads use every new core. This is the limit of the architecture: everything shares one machine, and while it restarts nothing answers. The next architectures move the databases out and add servers, without changing a single API.

Why choose this architecture

Lowest cost

One VPS from any provider. In our benchmark a 4 vCPU server answered ~7,423 requests per second.

Live in minutes

API Maker Launchpad sets up Docker, MongoDB, Redis, API Maker under systemd and Caddy with free HTTPS certificates.

Every feature included

Generated and custom APIs, schedulers, WebSockets, caching, Git deployment and logs: nothing is left out.

Fast by default

No network between API Maker and its databases: every query and cache read stays inside the machine.

Ready for Git

Perfect for DEV and QA: the same Git branches later deploy to the bigger architectures with a pull.

Easy to outgrow

Moving the databases out or adding servers later only changes connection strings in .env. Your APIs stay the same.

On video

Install API Maker v4 on Ubuntu with One Command

One command on a fresh Ubuntu server installs API Maker version four, its MongoDB and Redis, systemd to keep it running, and Caddy in front. A new server of Calm Home goes from nothing to its admin panel in under two minutes, then upgrades with the same command, keeps every version, and grows to more servers.

Every video of API Maker

Server configuration

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

All-in-one VPS

×1
CPU
2 – 4 vCPU
Memory
4 – 8 GB
Storage
40 – 80 GB SSD

Runs

  • Caddy: HTTPS, WSS and the admin panel, certificates from Let's Encrypt
  • API Maker, one Rust program run by systemd, on every CPU core
  • Docker: sandbox containers of custom code
  • MongoDB replica set: api_maker_db, api_maker_logs
  • Redis 7: internal and cache
  • Your database: PostgreSQL, MySQL, MongoDB…

Ports

  • 443: Caddy, HTTPS and WSS
  • 80: Caddy, certificates and the redirect to HTTPS
  • 38246 (APIs and WebSockets) and 4626 (admin panel): API Maker, closed to the internet, Caddy reaches them on 127.0.0.1

Minimum: 1 vCPU, 1 GB RAM with 2 GB swap, 20 GB storage, Ubuntu 24.04 LTS.

Settings of the server.env
am__serverName="primary"am__port="38246"   # the APIs and the WebSockets, on one port# The admin panel, served by API Maker itselfam__adminPanel__folder="/root/projects/api_maker/current/admin-panel"am__adminPanel__port="4626"# API Maker's own MongoDB, and its logs: on this serveram__mongo_db_connection="mongodb://mongo_user:***@127.0.0.1:38248/api_maker_db?authSource=admin&replicaSet=rs0&directConnection=true"am__logs__mongo_db_connection_logs="mongodb://mongo_user:***@127.0.0.1:38248/api_maker_logs?authSource=admin&replicaSet=rs0&directConnection=true"# One Redis for internal use and for the cacheam__redisInternal='{"nodes": [{port: 7479, host: "127.0.0.1", pass: "***"}]}'am__redisExternal='{"nodes": [{port: 7479, host: "127.0.0.1", pass: "***"}], redisValueExpireInSeconds: 7200}'
Caddy in front: HTTPS and WSS for API MakerCaddyfile
{    admin off}api.example.com {                  # HTTPS for the APIs    reverse_proxy 127.0.0.1:38246}ws.example.com {                   # WSS for the WebSockets: the same port    reverse_proxy 127.0.0.1:38246}admin.example.com {                # the admin panel, served by API Maker    reverse_proxy 127.0.0.1:4626}

API Maker Launchpad sets Caddy up with your domains: this is what it does, as a Caddyfile. API Maker has no TLS of its own: Caddy gets the certificates of these domains from Let's Encrypt and renews them by itself. Without SSL, it serves the APIs on port 8080, WebSockets on 8081 and the admin panel on 80, over plain HTTP.

systemd keeps API Maker runningterminal
systemctl status api_maker_be       # active (running), since when, its one processtail -f ~/logs/api_maker_be.txt     # what API Maker printssystemctl restart api_maker_besystemctl is-enabled api_maker_be   # enabled at install: back after every reboot

systemd starts API Maker again, a second later, if its process stops. API Maker is one process: it has no workers to watch.

Good to know

  • A single point of failure: when the VPS stops, every app stops. Keep snapshots of the VPS and dumps of the databases on another machine.
  • API Maker, the sandboxes and the databases share the same CPU, memory and disk.
  • It grows up only: a bigger VPS means a short restart while it is resized.
When you outgrow itYour database needs its own CPU, memory and disk. Separate database server

Questions

Is a single server enough for production?

For many apps, yes. In our benchmark (Linode, shared CPU, get all on MongoDB, 10 rows of 10 columns, the database on the same server) a 4-core VPS answered about 7,000 requests per second and an 8-core one about 11,000. Keep backups on another machine, since one server is also one point of failure.

Does API Maker serve HTTPS and WSS itself?

No. API Maker speaks plain HTTP and WebSocket on one port, 38246. Caddy, set up by API Maker Launchpad, receives every request first: it holds the certificates, from Let's Encrypt and renewed by itself, answers the apps over HTTPS and WSS, and passes the traffic to API Maker on the same server.

What happens when the API Maker process stops, or the server reboots?

systemd runs API Maker as the service api_maker_be. It starts it again a second after it stops, and the service is enabled at install, so it also comes back after every reboot.

What is the smallest server API Maker runs on?

1 CPU core, 1 GB of RAM with 2 GB of swap and 20 GB of storage, on Ubuntu 24.04 LTS. Give it 4 GB or more when your database runs on the same server.

Can I move to more servers later?

Yes. API Maker keeps your APIs, schemas and settings in its own MongoDB. Move the databases out, or add servers that point to the same MongoDB and Redis: only the connection strings in .env change.