Shared hosting, VPS, dedicated server or PaaS?

You can use shared hosting, a hosted PaaS, or your own servers. Shared hosting gives you a place for a site. A PaaS builds and runs your code on its infrastructure. Your servers can be virtual machines, called VPSs, or dedicated physical machines.

Tenkai is as simple as shared hosting, on servers you own. Add a database, deploy an application or ship a new version in a few clicks. You keep your provider account, your data and root access. You still plan capacity and recovery.

The short answer

The comparison below shows who does the server work, then compares price, performance and freedom. Switch on With Tenkai to see what changes on your own servers. Tenkai operates your VPS or dedicated servers; it does not replace them. Plans differ between providers.

Choose shared hosting if its supported software and limits fit your site. Choose a hosted PaaS if you do not want to manage servers. Choose your own servers for root access and control over the hardware and software, then decide whether to operate them yourself or use Tenkai.

Shared hosting

A provider hosts several customers on shared infrastructure. A typical plan gives you a control panel, PHP and MySQL, often with email. The provider manages the server. You maintain your site and its plugins.

You usually have no root access. The plan decides whether you can run Node.js, containers or background workers. CPU limits and other customers' activity can affect performance.

The entry price is usually low, with a fixed plan. Reaching its limits may mean upgrading or moving to another kind of hosting.

PaaS

A hosted platform as a service builds and runs applications on infrastructure it manages. Many platforms deploy from Git and offer databases, caches and workers.

You choose from its runtimes, regions and service limits. Compute, replicas, storage and traffic can be billed separately, and part of the bill may vary with usage. More capacity usually means a higher bill. Compare the total for your workload, including the server work you no longer do.

Your servers

Your provider supplies the machines. On an unmanaged plan, you operate the software above them, or let Tenkai do that work. A managed provider plan can also take on some of these jobs.

A VPS

A VPS is a virtual machine on a shared physical host. You usually get root access and a choice of operating system. CPU may be shared or dedicated, depending on the plan.

With an unmanaged VPS, you set up networking, HTTPS, deployments, databases and backups. When the VM stops, so do its applications. Recovery depends on the provider and the storage, not just on it being virtual.

A dedicated server

A dedicated server is a physical machine reserved for you. You manage it much like an unmanaged VPS. It can suit steady workloads that need a whole machine. Compare actual prices and hardware rather than assuming it is cheaper. A hardware failure may need a repair or a replacement.

Grouping servers into a cluster

A cluster is a way to coordinate workloads across your servers, not another hosting category. Its nodes can be VPSs or dedicated servers. It can replace a failed application's containers elsewhere, but that alone does not keep the application available. Traffic must still reach it, and its data must still be accessible.

Tenkai uses Docker Swarm to coordinate containers across your servers. Three manager nodes let it keep a majority after one manager fails. Replacement replicas also need spare capacity and access to their image. A lost edge node still stops public traffic. A database or an application that keeps files stays on its data node.

Where Tenkai sits

Tenkai automates the work on your servers. Bring a supported Debian or Ubuntu server, or let Tenkai create one in your Hetzner Cloud, DigitalOcean, Scaleway or Infomaniak Public Cloud account. Tenkai sets up the runtime, firewall, private network and routing. The dashboard and deployment workers run separately from your servers.

Deploy from a public Git repository, a container image or built static files. Tenkai builds Git sources and issues HTTPS certificates for your routes. For a static site, your CI sends the built files through a deploy hook. Add a PostgreSQL, MySQL, Redis® or Valkey service and link it to your application. Redeploy the application to receive its connection settings as environment variables.

For an application without kept files, a new version starts beside the old one and passes readiness checks before traffic switches. The old version keeps its routes until the new one takes traffic. An application that keeps files stops before its replacement starts.

Tenkai also assists scaling. Choose the replica count and apply the configuration; Tenkai runs those replicas and automatically balances web traffic across them. You provide capacity. This is not demand-based autoscaling, and an application that keeps files stays on one replica.

Hako, Tenkai's assistant, can help every team diagnose a failed deployment. It reads the available configuration and logs. A diagnosis does not replace checking the application or testing a backup.

What stays yours:

• Your provider bills you for the servers. Running applications do not need the Tenkai dashboard to stay online. Tenkai charges for a Team plan with a server limit, not per service or replica.
• Team members can log in as root once an owner or admin authorizes their SSH keys on that server.
• Databases and kept files live on your servers. Choose a storage bucket outside the cluster to enable encrypted daily backups.

Tenkai reserves some CPU and memory for the system and its services. This figure shows what is left on the first server. Select Build from a Git repository to include the build reserve, which new clusters use by default.

What you still decide

Automation does not remove these decisions:

• After setup, owners and admins choose when to install package updates and when to reboot. Tenkai's update action leaves Docker Engine and held packages unchanged.
• You provide capacity for applications, replacement replicas and deployments that briefly run two versions.
• You plan recovery and test backups. Check the latest successful copy and measure how long a restore takes.

When another option suits better

• One small PHP site. A shared plan may cost less and need less server work. Tenkai needs at least 2 GB of memory on the first server.
• No server at all. If nobody in your team wants to own a provider account, a server or its capacity, a PaaS asks less of you.
• A different system or deployment workflow. Tenkai sets up Debian and Ubuntu only, builds from public Git repositories only, and does not deploy a Docker Compose file. A cluster receives its public traffic on one edge node, so its traffic stops when that node fails.
• Full control of every setting. Tenkai writes the Docker settings for you. On a bare VPS, you set each one yourself.

Choose Tenkai when you want the machine without its daily setup and deployment work: shared-hosting simplicity, with your servers and root access.

Go further

• What is Tenkai?Understand where Tenkai runs your applications, how a server becomes a deployment platform and what you remain responsible for.
• How Tenkai runs your applicationsSee what Tenkai does from its control plane, what runs on your servers and how a deployment reaches them.
• Clusters and node rolesUnderstand the edge node, manager nodes, worker nodes and data nodes, how many failures a cluster survives, and how to keep replicas on separate nodes.
• How much memory a server needsSee 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.
• Plans and billingSee how many servers each plan allows, subscribe, upgrade or switch to a lower plan, change the card, read the invoices and cancel the subscription.
• Compare Tenkai with Coolify and DokploySee what Coolify and Dokploy leave to you in production, from the cluster to database failover, backups and the versions of your apps.

Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd.