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 PHP, a MySQL database, and a web interface. No terminal, no DevOps, no stress.

But at some point, shared hosting stops being enough. The question is: when exactly does that happen — and is Kubernetes really the right answer?

Where Shared Hosting Falls Short

Shared hosting works beautifully for WordPress sites, simple PHP applications, and static websites. Problems start when any of these scenarios apply:

1. Your Application Isn’t PHP

You’ve written an API in Go, Python, or Node.js? A worker process handles jobs from a queue? Shared hosting typically only supports PHP and static files. Anything else requires at least a VPS.

2. You Need Multiple 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 can run a database and a PHP process at best. Everything else needs its own server — and its own management overhead.

3. Deployments Are Manual

If you’re uploading code via FTP or deploying through a web panel, you’re missing reproducibility. What happens when a deployment fails? How do you roll back? Who deployed what, and when?

4. Scaling Is Impossible

Shared hosting splits a server’s resources across dozens of other customers. If your application needs more CPU or RAM during peak hours, there’s nothing you can do about it.

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 (+ static)	Anything that runs in a container
Multiple services	No	Yes, unlimited
Deployments	FTP / web panel	kubectl apply / GitOps
Rollbacks	Manual	Automatic (deployment history)
Scaling	Not possible	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 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 (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.

Making the Switch in Practice

Step 1: Containerize Your Application

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

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

FROM node:22-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 Starter (€19/mo)
Price	€10/month	€19/month
Languages	PHP	All
Services	1	Unlimited
Deployments	FTP	GitOps
TLS	Yes	Yes (automatic)
Scaling	No	Yes
Backups	Daily (DB only)	Daily (complete)
Location	Varies	Germany
GDPR	Provider-dependent	Included

For €9 more per month, you get a fundamentally different infrastructure — reproducible, scalable, and independent of any particular programming language.

Conclusion

Shared hosting isn’t bad — it’s simply built for a specific use case. 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 →