Glossary

Hosting where several customers share a server and its software, often PHP and MySQL. The host runs the server; you upload your site without root access.

A virtual machine on a physical server shared with other customers. You get your own operating system and root access, then set it up yourself or let Tenkai prepare a supported Debian or Ubuntu release.

A physical machine that no other customer uses. Tenkai sets up a supported Debian or Ubuntu server the same way, whether it is dedicated or a VPS.

A platform that builds and runs applications without asking you to manage servers. A hosted PaaS supplies the machines. Tenkai instead automates the work on your own VPS or dedicated servers, which stay with your provider.

A deployment platform you run on your own server, including its dashboard and deployment jobs. Tenkai is not self-hosted: it hosts the control plane, while your servers run your applications.

Use servers you own or rent, even at different providers. Tenkai needs Debian 12 or Ubuntu 24.04 or later, root access for enrollment, SSH access and WireGuard connectivity between nodes. All nodes of a cluster must share one CPU architecture.

Tenkai's dashboard, configuration database and deployment jobs. It instructs your servers over SSH but carries no application traffic, so running applications do not depend on it being available.

The initial installation of Docker Engine, the firewall and the cluster network on a server. Tenkai also disables SSH password logins and installs its monitoring agent unless the cluster has that option turned off.

One or more servers, called nodes, that run your resources together. A cluster groups VPSs or dedicated servers; it is not a hosting category. It places application replicas on nodes with room for them; resources that keep files stay on their data nodes.

A node that keeps the cluster state and helps decide where replicas run. Managers can also run workloads. Stop accepting workloads moves their applications away, but leaves stateful resources in place.

A node that runs workloads without voting on cluster changes. Add one when your applications or databases need more CPU or memory.

More than half the managers, able to agree on cluster changes. That means 2 of 3 or 3 of 5. Without quorum, containers on surviving nodes keep running, but Swarm cannot replace lost replicas or apply service changes.

The node whose disk holds a database, an application's kept files or cluster storage. Those files stay on that node. Losing its disk requires a backup or an external copy.

A group of resources, such as a shop, its queue worker and its database. Its production environment runs on the cluster you choose.

An application that answers HTTP requests on its configured port, 8080 by default. Tenkai runs it from Git, a container image or uploaded static files and gives it an HTTPS address.

One running copy of a web application or worker. Choose 1 to 10 replicas, each reserving its own CPU and memory; a web application that keeps files is limited to 1.

An application that runs continuously in the background, such as node ace queue:work. Tenkai gives it no public route or published port.

An application that runs a command on a schedule, then stops. For example, 0 3 * * * runs at 03:00 UTC each day, with no CPU or memory reserved between runs.

Tenkai checks a new version beside the running version, gives it higher-priority routes, then removes the old routes and stops the old version. An application with kept files stops before its replacement starts.

A deployment without a service interruption. Tenkai overlaps routes so switching versions leaves no routing gap. Applications with kept files still stop during deployment, and the old process must finish requests already in progress.

A directory a web application keeps on one data node across deployments. The application runs one replica there and stops before its new version starts. It cannot run while that node is down.

File storage accessed through an API, not a local directory. Tenkai runs S3-compatible hosted buckets on one data node, each with its own keys and size limit. An optional bucket copy mirrors files outside the cluster, including deletions.

PostgreSQL, MySQL, Redis® or Valkey run by Tenkai on your cluster. A binding gives an application its connection details at the next deployment; the data stays on your servers.

An encrypted copy of database data or application files in your storage bucket. Choosing a bucket enables daily backups for PostgreSQL, MySQL, Redis® or Valkey. Tenkai keeps the 7 latest successful copies.

An S3-compatible bucket you provide outside your clusters for backups and bucket copies. It is separate from a hosted bucket, which stores application files on a cluster.

Getting applications and data back after a failure. Tenkai replaces application replicas while enough managers and capacity remain. To recover lost data, you need a successful backup. You rebuild a lost cluster yourself, since Tenkai keeps none on standby.

The manager node that receives public web traffic on ports 80 and 443. A cluster has one. Losing it stops public traffic, even when application replicas run elsewhere.

A server that forwards requests to applications. Tenkai uses Traefik on the edge node to handle HTTPS and route requests by hostname to each application's configured HTTP port.

A service that spreads requests across running copies of an application. Tenkai balances traffic across web application replicas, but does not provide a load balancer in front of its single edge node.

A hostname you own, such as app.example.com, added to a web application. Point it to the default route with a CNAME, or to the edge node with an A record. Tenkai checks DNS and issues its HTTPS certificate once the application is deployed.

The WireGuard network that encrypts runtime traffic between cluster nodes on UDP port 51820. It works across providers or over a shared private network.

The private application network for a project's production environment in its cluster. Applications reach databases by their runtime names. The edge router joins it too, so it is not a complete security boundary.

A certificate that lets a browser verify an HTTPS hostname. Tenkai obtains it from Let's Encrypt and sends it to the edge node before routing the hostname. Tenkai also renews certificates. If renewal fails and the certificate expires, browsers show a warning.

Rules that allow or block network connections. Tenkai allows SSH, HTTP and HTTPS through ufw, plus WireGuard from cluster peers. Existing rules and Docker-published ports can allow more.

A key pair used to log in over SSH. For your personal key, Tenkai stores only the public half. An owner or admin can authorize it for root access. Tenkai has a separate automation key for each server.

Your team's key pair for encrypting and decrypting backups. An owner or admin can download it to read backups without Tenkai. Keep the file outside Tenkai and download it again after a rotation.