API Maker
The backend engine for the AI era
Security
Your code runs in Docker containers, apart from the API Maker process, with time limits and automatic replacement.
Custom APIs, hooks, event listeners, schedulers, migrations and test cases run in sandbox containers, not in the API Maker process. Every language has a sandbox of its own, every run has a time limit, a stuck sandbox is replaced, and each account chooses the runtime, the version and the packages its images are built with. Sandboxes keep faulty code away from the engine. They are not a wall against hostile code: give code access only to people you trust.
Step through it, slow it down, or open the full canvas.
api-maker/features/secure-sandboxLiveYour code runs outside API Maker. Custom APIs, hooks, event listeners, schedulers, migrations and test cases run in Docker containers, each language in a sandbox of its own, which every thread of API Maker uses. API Maker hands the request to the sandbox over TCP and gets the answer back.
Custom APIs, hooks, event listeners, schedulers, migrations and test cases run in Docker containers, each language in a sandbox of its own, which every thread of API Maker uses. API Maker hands the request to the sandbox over TCP and gets the answer back.
The sandbox holds API Maker itself, as a library of the runner of your language. g.sys.db.query is a function call there: it runs the real API with its checks, and reads the database from the sandbox.
13 seconds by default. Change it per request with the x-am-sandbox-timeout header, or in the settings of a custom API, a scheduler or a listener.
It gets no new requests, the ones inside it finish, then it is removed and a new sandbox takes its place. The time to get a sandbox is not counted in the logs.
Each language of an account gets an image built from its runtime, your packages and your Dockerfile, on every server. Save the settings and the sandboxes start anew from the new image.
A runtime and a version per language, the sandbox count of every server or of each one, a separate sandbox for a heavy API, or the native process for code you trust.
An endless loop or a crash in your code stays in its container, and API Maker keeps serving the other requests. A container has no memory limit of its own: code on Node.js has a heap limit, code of the other languages uses the memory of the server.
Give a heavy custom API a sandbox group of its own, with its own runtime, version, packages and Dockerfile.
Turn on debugging and stop your code at breakpoints, in every language and on the native process too, right in the admin panel. The debug engine is published nowhere: the server alone reaches it, through the agent of the sandbox.
Generating PDFs needs a big package and a lot of memory. In its own sandbox group, it gets its package and its own sandboxes, while every other API keeps its small, fast ones.
import * as T from 'types';let customApi: T.ICustomApiSettingsTypes = { name: 'Invoice PDF', requestMethod: T.ERequestMethod.POST, path: '/invoice-pdf', customApiTimeoutInSeconds: 60, separateSandboxSettings: { enableSeparateSandboxForThis: 'pdf_group', sandboxCount: 1, packages: { allowAllPackagesOfAdmin: false, sandboxPackages: [{ name: 'pdfkit', version: '0.15.0' }] }, }, errorList: [],};module.exports = customApi;On the real admin panel, with real data.
One by default (Auto): on each server, the first request of a language of an account starts one sandbox, and every thread of the API Maker process uses it. A sandbox does not belong to a thread. It opens more runners while all of its runners are busy, up to as many as the server has CPU cores. Set a higher sandbox count in Sandbox settings, for every server or for one, and more sandboxes start while there is work. Idle sandboxes go after the minutes you set, or never. A sandbox group has a pool of its own, and a request waits when everything is busy.
Through g.sys.db. The sandbox holds API Maker itself, as a library of the runner of your language: the call is a function call inside the sandbox, which runs the real API with its checks and reads the database from there.
Yes. Send x-am-sandbox-timeout in milliseconds, or set the limit in the settings of the custom API, scheduler or listener.
