Deploy with Tenkai

Understand where Tenkai runs your applications, how a server becomes a deployment platform and what you remain responsible for.

Deploy your first web application on Tenkai from a public container image, configure its runtime port and check the HTTPS route.

Understand how Tenkai groups resources, prepares clusters and creates the production environment for your project.

See what a team owns, create a team and switch between your teams, rename it, change its icon, choose what a new cluster starts with, and read what each team role may do.

See how many servers each plan allows, subscribe, upgrade or switch to a lower plan, change the card, read the invoices and cancel the subscription.

Change your password, sign in with GitHub, choose the theme, and find the credentials that belong to you rather than to a team.

Read the page Tenkai opens when you sign in: the first steps of a new team, the requests of an agent that wait for you, health, the latest deployments, the load of each cluster and the traffic of each project.

See what Coolify and Dokploy leave to you in production, from the cluster to database failover, backups and the versions of your apps.

See what Tenkai does from its control plane, what runs on your servers and how a deployment reaches them.

Understand the edge node, manager nodes, worker nodes and data nodes, how many failures a cluster survives, and how to keep replicas on separate nodes.

Mix Hetzner Cloud, DigitalOcean, Scaleway, Infomaniak Public Cloud and your own hardware in one cluster, linked by an encrypted WireGuard mesh.

Follow a request from DNS to the edge node, through HTTPS and the edge router, to a replica on any node of the cluster.

Understand the blue-green deployment: Tenkai starts a candidate next to the active release, checks it, then moves the routes to it.

See how Tenkai moves each web application and each worker off a node before maintenance or removal, and what cannot move.

Deploy from a Git repository with a Dockerfile, build from source, use a container image from Docker Hub or GHCR, or send the files of a static site.

Configure environment and resource variables, protect credentials and choose the port your HTTP server listens on.

Write a production Dockerfile with npm for a Node.js HTTP application, deploy it from a Git repository and verify its default HTTPS route.

Package a Laravel application with FrankenPHP, connect it to PostgreSQL, run its migrations and deploy it from a Git repository.

Build a Vite, React or Vue application in your CI, send its files to the deploy hook of a static site and choose how a missing path answers.

Create a GitHub token for GHCR, add it as your GHCR credential, link it to a resource and replace it before it expires.

Build your Dockerfile in GitHub Actions, publish the image to GHCR for the architecture of your cluster and deploy each new version.

Enable the deploy hook of an application, call it from GitHub Actions or any CI tool, wait for the deployment to end, and rotate or revoke its secret.

Turn on deploy on push for an application built from a GitHub repository, follow each deployment beside its commit, and know what happens to pushes during a deployment.

Turn on pull request previews for a project, so each pull request gets its own environment, deployed on each push and deleted once it closes.

Give a web application pre-deploy commands for its database migrations and rollback commands to undo them, and know when each runs and what a failure does.

Create a worker for a queue consumer or another background process, set its entrypoint and replicas, deploy it and roll it back.

Create a scheduled job, write its schedule as a cron expression in UTC, deploy it, and know how your cluster starts its runs while Tenkai is down.

Ask a web application to keep a directory between two deployments, in a volume on one node of your cluster, and know what that changes for it.

Install a ready-made app such as Umami or WordPress into a project, with the web application, the database and the kept files it needs, and see what to do when it does not start.

Read the traffic tab of a web application: its requests by status class over time, what counts as a request, and what a gap in the chart means.

Create PostgreSQL, MySQL, Redis® or Valkey, bind an application, back it up and understand storage and recovery limits.

Send encrypted backups of a database, or of a web application that keeps files, to your own storage bucket, restore one, create a database from it and read it without Tenkai.

Turn on high availability for a PostgreSQL: what it protects against, what it costs, what a cluster needs, and why it does not replace backups.

Run an S3-compatible storage on a node of your cluster, give a web application its own bucket and keys, and know what happens to the files when the node is lost.

Connect your domain to a Tenkai web application with a CNAME or an A record, and verify automatic HTTPS.

Let clients outside the cluster reach a TCP port of a web application, such as SSH to clone and push to a Git host.

Create a token for Hetzner Cloud or DigitalOcean, a secret key and a project ID for Scaleway, or an application credential for Infomaniak Public Cloud, with the permissions Tenkai needs, then connect it.

Add or generate an SSH key, authorize it on the servers of your team and log in as root, then revoke it when it should no longer work.

See the memory Tenkai keeps on each node for the system, builds and its own services, why it keeps it, and what is left for your applications.

Add a node, make a cluster highly available, drain or resume a node, remove a worker node, and choose whether new servers get the Tenkai Agent.

What etcd does for a PostgreSQL with high availability, what it reserves on the manager nodes, how to read its state on the cluster page, and what it changes for a reboot or a drain.

Read the upkeep report of a server, install its package updates, reboot it without surprise and open a root terminal from Tenkai.

Sign in from Claude Code, Cursor or another MCP client, or create an agent token for an agent that cannot, and approve the deployments and servers the agent asks for.

Read the health tab of a web application or a worker: what a runtime drift is, what Tenkai compares with the running service, and how to put back what Tenkai records.

Read the health page: failed deployments, custom domains that are not ready, services changed outside Tenkai, disks almost full, and servers that need an update or a reboot.

Read the logs of a deployment and find the next check for a failed build, an application that does not respond, incorrect DNS or an HTTPS verification failure.

Follow what the containers of a web application or a managed service write, search it, and open a shell inside a running replica.