API Maker

The framework for 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. One install script sets it all up, 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
Workers
4CPU cores
Capacity
~2,759req/s
Cache hits
0%of reads

One command sets it up. The install script puts MongoDB, Redis, API Maker under systemd and Caddy on a fresh Ubuntu VPS. Your database can live on the same server.

How it works

The same steps as the diagram, in more detail.

  1. One command sets it up.

    Run the install script on a fresh Ubuntu 22.04 VPS. It installs Docker, starts MongoDB 6 as a replica set and Redis 7 in containers, then API Maker, 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 serves 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 on port 38246 and WebSocket on port 38245. Caddy, set up by the install script, 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 to 127.0.0.1:38246, ws.example.com to 127.0.0.1:38245 and serves the admin panel on admin.example.com. 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 runs as a cluster: with cpuCount set to AUTO it starts one worker per CPU core (limited by the memory, one worker per 2 GB), and the requests are shared between them. If a worker exits, the cluster starts it again on its own.

  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 on the table resets its cache, so no one reads stale data. Keys expire on their own after 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 38245. 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. The worker that answers the call publishes the event in Redis, and the worker 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) runs in sandbox containers managed by API Maker. Each worker has its own sandbox, so custom code never blocks the generated APIs and cannot reach the files of the server.

  7. systemd keeps API Maker running.

    The install script sets API Maker up as the systemd service api_maker_be and enables it, 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. Inside it, the cluster of API Maker restarts any worker that exits on its own. 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 cpuCount AUTO starts a worker on 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 ~2,759 requests per second.

Live in minutes

The install script 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.

Server configuration

Plain VPS from any provider, or your own servers, with Ubuntu 22.04 LTS. 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 backend, run by systemd, cpuCount AUTO
  • Docker: sandbox containers of custom code
  • MongoDB 6 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 and 38245: 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 22.04 LTS.

Install on a fresh Ubuntu VPSterminal
curl -fsSL https://apimaker.dev/v1/install.sh > install.sh && bash install.sh --default --version=latest

It installs every dependency, starts API Maker as a systemd service, sets up Caddy and prints the URLs at the end. Answer yes to SSL and give your domains to get HTTPS: --default only skips the questions about ports and passwords.

Settings of the server.env
am__serverName="server1"am__port="38246"      # HTTP APIsam__wsPort="38245"    # WebSocket notificationsam__cpuCount="AUTO"   # a worker per CPU core# 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 Maker~/config/Caddyfile
{    admin off}api.example.com {                  # HTTPS for the APIs    reverse_proxy 127.0.0.1:38246}ws.example.com {                   # WSS for the WebSockets    reverse_proxy 127.0.0.1:38245}admin.example.com {                # the admin panel    root * /root/projects/sava_api_maker/dist    file_server    encode zstd gzip    try_files {path} /}

Written by the install script. 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 processestail -f ~/logs/api_maker_be.txt     # what API Maker printssystemctl restart api_maker_besystemctl is-enabled api_maker_be   # enabled by the install script: back after every reboot

systemd starts API Maker again if its process stops. Inside it, the cluster of API Maker restarts any worker that exits.

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, MongoDB 6, 10 rows of 10 columns) a 4-core VPS answered about 2,759 requests per second and an 8-core one about 4,529. 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 on port 38246 and WebSocket on port 38245. Caddy, set up by the install script, 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 install script enables the service, 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 22.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.