List of runtimes

GET /v1/infra/runtimes

Returns the IDs of ready-made runtimes to pass into POST /v1/infra/servers/:id/deploy (the runtime parameter). The runtime parameter is optional: if the stack you need is in the list, pass its ID and the platform will install the packages automatically. If not, a deploy without runtime on a dedicated virtual machine still works fully — install the software you need via preStart in the request body. For a Galaxy application runtime is required and preStart does not apply. On POST /v1/infra/servers a runtime without source has NOT been accepted since 2026-04-25 — see RUNTIME_PARAM_REMOVED. When a Galaxy application is created in one step, runtime is passed together with source; start is also required unless the runtime is static, where it is optional and ignored. Each runtime is a set of system packages (nodejs, python, nginx, databases) installed on the server. The estimated installation time is 2–4 minutes for the basic ones, up to 4+ minutes for combinations with several packages.

Examples

curl — personal key

curl -H "X-Api-Key: YOUR_API_KEY" \
  https://vibecode.bitrix24.com/v1/infra/runtimes

curl — OAuth application

curl -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  https://vibecode.bitrix24.com/v1/infra/runtimes

JavaScript — personal key

const res = await fetch('https://vibecode.bitrix24.com/v1/infra/runtimes', {
  headers: { 'X-Api-Key': 'YOUR_API_KEY' },
})
const { data: runtimes } = await res.json()
runtimes.forEach(r => console.log(`${r.id}: ${r.name} (${r.estimatedSetupTime}s)`))

JavaScript — OAuth application

const res = await fetch('https://vibecode.bitrix24.com/v1/infra/runtimes', {
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
  },
})

Response fields

Response example

{
  "success": true,
  "data": [
    {
      "id": "node20",
      "name": "Node.js 20",
      "packages": ["nodejs-20", "npm", "pm2"],
      "estimatedSetupTime": 120,
      "supportedPlacements": ["standalone", "galaxy"]
    },
    {
      "id": "node20-pg",
      "name": "Node.js 20 + PostgreSQL",
      "packages": ["nodejs-20", "npm", "pm2", "postgresql-16"],
      "estimatedSetupTime": 180,
      "supportedPlacements": ["standalone"]
    },
    {
      "id": "python311-rag",
      "name": "Python 3.11 + RAG (pgvector + Redis)",
      "packages": ["python3.11", "pip", "postgresql-16", "pgvector", "redis"],
      "estimatedSetupTime": 240,
      "supportedPlacements": ["standalone"]
    }
  ]
}

Error response example

401 — no API key provided:

{
  "success": false,
  "error": {
    "code": "MISSING_API_KEY",
    "message": "API key required. Pass via X-Api-Key header."
  }
}

Errors

Full list of common API errors — Errors.

Known specifics

• As of 2026-04-22 the platform offers 15 runtimes: six Node.js 20 variants (plain, with PostgreSQL, MySQL, Redis, combinations, the RAG stack), five Python 3.11 variants (similarly), two PHP 8.3 variants (plain and with MySQL), and static for SPA static content. The current snapshot is always in the endpoint's response.
• The start command depends on the runtime — pass it in the deploy start field, except for static. For static, the field is optional and ignored: the platform starts nginx itself. Other runtimes use versioned commands on a dedicated virtual machine: node20* — node, python311* — python3.11, and php83* — php8.3. There is no python command on such a machine, and python3 stays the Ubuntu 24.04 system interpreter — that is version 3.12. The python3.11 command works in Galaxy too, so such a start fits both placement models. The runtime binds pip to 3.11, so pip install in the install field puts dependencies into the same interpreter that runs the app.
• The pm2 package in a runtime's list is a tool installed on the machine, not a way to start the application. The node20 runtime and its variants install pm2 alongside Node.js, but the start field requires a command that stays in the foreground and holds the listener itself. A command such as pm2 start server.js --name app && pm2 save launches a daemon and exits, and the platform stops the application service along with it. The full rule, both outcomes of such a command and what tells them apart in the deploy result — Full deploy, "Known specifics".
• Where pip fetches packages from. The platform sets a default package index — the canonical PyPI (pypi.org). The setting is machine-wide, so it covers the automatic requirements.txt install, your own command in the install field, and any pip you run by hand through exec. Your choice wins over ours: an --index-url in requirements.txt or in the install command overrides the default. A PIP_INDEX_URL from the deploy env does NOT affect a Galaxy build — the environment reaches the container at runtime, while dependencies are installed earlier, during the image build; on a dedicated virtual machine it does work. If package immutability matters to you, use --require-hashes with pinned hashes — that is the only mechanism protecting you from substitution on the index side. poetry and uv do not read our setting; point them at an index using their own configuration mechanism.
• Where npm and apt fetch packages in Galaxy. Before the build, the platform sets machine-wide npm and Debian configuration, so both automatic installation and the install command see it; deploy env does not affect those build steps. An npm command's own registry or custom Debian sources override the default.
• RAG runtimes (node20-rag, python311-rag) — a ready-made environment for the RAG pattern (retrieval-augmented generation — an LLM response enriched with context from external sources): PostgreSQL with the pgvector extension for embeddings and Redis for caching. Right after installation you can connect LlamaIndex / LangChain.
• Nginx in static, php83, and php83-mysql. On a dedicated virtual machine the runtime installs the package before stopping the previous application, but it does not start the system nginx.service or leave it newly enabled. For static, the listener is started by the managed app.service; PHP recipes keep their own start commands.
• static — a runtime for single-page applications and static sites. Send an archive containing the ready build, runtime: "static", and the desired port (default 3000); start is optional and ignored in every placement. The remaining behavior is placement-specific. On a dedicated virtual machine with the usual systemd: true, the platform creates the nginx configuration, serves extractTo (default /opt/app), and runs nginx under an unprivileged account; the document root must be a nested application directory under /opt or /srv, while every /var/lib path and /opt/data are refused. With systemd: false, the platform creates neither an nginx configuration nor a unit: the pre-existing unit must listen on the selected port itself. In Galaxy, files always live at /opt/app inside the container, extractTo and standalone settings are ignored, and the container runs nginx with its fixed command. The managed configurations in both placements fall back to index.html for client-side routes, check the complete path chain for symlinks, and do not serve hidden files including .env. Multipart deploys still require the port field.
• The php83 and php83-mysql runtimes, and the MySQL variants (node20-mysql, node20-mysql-redis, python311-mysql), need "hardening": "off". After installation MySQL allows only the administrator to connect over the local socket, and PHP-FPM runs as a separate system service — under an unprivileged account the app cannot reach the database. The platform restores the previous mode on its own, but the attempt and its health check cost time on every deploy. Pass "hardening": "off" in the deploy body to skip it. Apps that reach MySQL over TCP with a password do not need this.
• Combo runtimes run on a dedicated virtual machine only. The -pg / -mysql / -redis / -rag suffixes describe the dedicated-machine template: there, PostgreSQL / MySQL / Redis really is installed alongside the language. A Galaxy app is a single language container on a shared host — no database is started there and no connection variables (DATABASE_URL, PG*, etc.) are injected, so deploying such a runtime into Galaxy is refused: a 400 with code GALAXY_RUNTIME_DB_UNSUPPORTED, a details.suggestedRuntime field (the language replacement — node20 instead of node20-pg, for example) and a hint. Which runtime fits which placement is machine-readable in the catalog GET /v1/infra/runtimes: every entry carries supportedPlacements — ["standalone"] or ["standalone","galaxy"]. The name and packages fields describe the dedicated-machine install and do not change. If a Galaxy app needs a database, take a language runtime and pass the connection string of an external (managed) DB through env, or deploy the app to a dedicated virtual machine with the original runtime.
• The same runtime ID can mean different patch versions in Galaxy versus on a dedicated virtual machine. In Galaxy the runtime is built from an official Docker image (node:20-slim, python:3.11-slim, php:8.3-cli, nginx:alpine) — the version follows the image tag. On a dedicated virtual machine the major version is pinned and matches what is advertised (Node.js 20, Python 3.11, PHP 8.3, PostgreSQL 16); the patch version follows the install source. If the exact version is critical, check it inside the app on the target placement rather than relying on the runtime ID alone.
• estimatedSetupTime is an estimate, not a guarantee. It depends on the load of the apt mirrors, the network speed of the virtual machine, and the specific Ubuntu image build. Budget 2× the stated value when automating.
• If the stack you need is not in the list — use preStart on a dedicated virtual machine. The server is a clean Ubuntu 24.04 with root access. In the deploy's preStart field you can run any apt-get install, download binaries, set up the environment. The result is preserved between deploys (except for the extractTo directory, which cleanDeploy: true cleans). For one-off operations — POST /exec.

See also

• Create a server
• Full deploy
• Get a server