Kubernetes vs. Shared Hosting: When Is It Time to Switch?

Shared hosting is where most web projects start, and for good reason. For €5–15/month, you get a runtime, a database, and a web interface. No terminal, no DevOps, no stress.

But at some point, a project outgrows shared hosting. The question is: when exactly does that happen, and is Kubernetes really the right answer?

When a Project Outgrows Shared Hosting

Shared hosting works beautifully for WordPress sites, classic PHP applications, small Node or Python apps, and static websites. A move becomes worth considering when any of these scenarios apply:

1. Your Runtime Isn’t on Offer

Modern shared hosting stopped being PHP-only a long time ago. ITSH web hosting runs PHP 8.2 through 8.5, plus purely static sites. It gets tight as soon as you need a different runtime: Node.js, Python, Go, Rust, Java, or an application that ships its own system packages and binaries. At that point you need a container image, and with it Kubernetes or at least a VPS.

2. You Need Multiple Long-Running Processes

A modern SaaS product rarely consists of a single application. A typical stack looks like:

• API backend
• Frontend (SPA or SSR)
• Background worker
• Database
• Redis/cache

On shared hosting, you typically cover the web application, cron jobs, and the database. There’s no room for a permanently running queue worker, your own cache, or a message broker. Those need their own servers, and with them their own management overhead.

3. Deployments Aren’t Reproducible

If your deployment is an FTP upload or a few clicks in a web panel, you’re missing reproducibility. What happens when a deployment fails? How do you roll back? Who deployed what, and when? Many hosts now offer git deployments, which solves the upload but not the declarative state: there’s no deployment history, no rollback in a single command, and no environment you can rebuild from scratch out of a repository.

4. Scaling Hits the Plan Ceiling

Shared hosting splits a server’s resources across other customers. Your site scales within the limits of your plan, but you don’t decide how many instances of a given service run, and you can’t direct load at individual components. A horizontal pod autoscaler that replicates exactly the one overloaded service isn’t something shared hosting provides.

5. Vendor Lock-in Through Proprietary Tools

Many hosts offer custom deployment tools, database panels, and configuration interfaces. Migrating to a different provider often means rebuilding parts of your infrastructure from scratch.

What Changes with Kubernetes?

Kubernetes solves these problems, but at the cost of complexity. Here’s an honest comparison:

Criterion	Shared Hosting	Kubernetes
Supported languages	PHP, Node.js, Python (host-dependent)	Anything that runs in a container
Multiple services	Limited (web app + cron jobs)	Yes, unlimited
Deployments	FTP / git / web panel	kubectl apply / GitOps
Rollbacks	Manual	Automatic (deployment history)
Scaling	Vertical, within your plan	Horizontal Pod Autoscaler
Reproducibility	Low	Complete (Infrastructure as Code)
Barrier to entry	Very low	High (without a managed service)
Price	€5–15/month	From €3/month (ITSH PAYG)

The key insight: Kubernetes isn’t automatically more expensive than shared hosting. The cost depends on how you run it.

The Middle Step Most People Skip

Between shared hosting and Kubernetes, there’s a logical middle step: a VPS with Docker. For many scenarios, that’s enough, and it’s a good way to learn container fundamentals.

# On a VPS: Docker Compose for a simple setup
docker compose up -d

The problem: the moment you need high availability, automatic restarts, rolling updates, or scaling, you end up rebuilding Kubernetes piece by piece, just worse.

When Kubernetes Makes Sense

Kubernetes is worth it when at least two of these apply:

1. You run more than one long-running service (API + worker + frontend)
2. Deployment downtime is unacceptable (rolling updates required)
3. You want Infrastructure as Code (reproducible environments)
4. Your application needs to scale horizontally (more replicas under load)
5. You maintain multiple environments (staging + production)

If only point 1 applies, Docker Compose on a VPS is probably fine. Once two or more apply, Kubernetes becomes compelling.

If you’re not sure yet whether Kubernetes is the right answer, the cheapest way to find out is to actually try it: ITSH offers a perpetual free namespace, no credit card, no commitment. Deploy your real app on it for a week before deciding anything.

Making the Switch in Practice

Step 1: Containerize Your Application

Each component gets a Dockerfile. A typical Node.js example:

FROM node:24-alpine AS build
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile
COPY . .
RUN yarn build

FROM node:24-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/server.js"]

Step 2: Write Kubernetes Manifests

A simple Deployment with a Service:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:latest
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 3000

Step 3: Set Up GitOps

ITSH comes with ArgoCD pre-configured. You connect a Git repository to your namespace, and every push to the main branch is automatically rolled out.

# Check deployment status
kubectl get pods -n my-namespace
kubectl rollout status deployment/api -n my-namespace

Step 4: DNS and TLS

ITSH handles TLS certificates automatically. You just need to create an HTTPRoute and point your DNS record.

What You Don’t Need

The most common mistake when starting with Kubernetes: trying to do everything at once. You do not need the following on day one:

• Helm Charts: Plain YAML manifests are fine for getting started.
• Service Mesh (Istio/Linkerd): Only relevant with dozens of services.
• Custom Operators: Standard resources cover 95% of use cases.
• Multi-cluster setup: A single namespace is enough for most SMB workloads.

With a managed namespace on ITSH, you also skip all cluster administration: no etcd, no nodes, no ingress controller configuration.

Cost Comparison: Shared Hosting vs. ITSH Namespace

For a typical web application (API + frontend + database):

	Shared Hosting	ITSH Namespace S (€15.00 gross/month)
Price	€10/month	€15.00/month
Languages	PHP, Node.js, Python	Anything that runs in a container
Services	Web app + cron jobs	Unlimited
Deployments	FTP / git	GitOps (ArgoCD)
TLS	Yes	Yes (automatic)
Scaling	Vertical, within your plan	Horizontal (HPA)
Backups	Daily (DB)	Daily (restore via support)
Location	Varies	Germany
GDPR	Provider-dependent	Included

For €5 more per month, you get a fundamentally different infrastructure: reproducible, horizontally scalable, and independent of whichever runtimes a host happens to offer. Storage isn’t part of the fixed tier, PVCs are billed separately.

Conclusion

Shared hosting isn’t bad, it’s built for a specific use case and serves it well. When your project outgrows that use case, Kubernetes is the logical next step. And thanks to managed namespaces, that step doesn’t have to be expensive or complicated.

You don’t need a DevOps team or a cloud certification. You need a Dockerfile and a few YAML manifests.

Try a managed Kubernetes namespace from €3/month →