Self-Hosting Like a Pro, Part 2: Docker, K3s and Traefik v3 with Automatic HTTPS

This is Part 2 of a four-part series where I document how I turned a 10€/month VPS into a production-grade platform hosting multiple projects. In Part 1 we hardened a fresh Ubuntu server. Today we install the actual platform: a container runtime, a lightweight Kubernetes distribution, a modern reverse proxy, and automatic TLS certificates. By the end of this article, deploying an app with HTTPS will take one YAML file and zero manual certificate handling.*

Why Kubernetes on a single VPS?

Fair question. Docker Compose would work, and for a single project I would recommend it without hesitation. But my server hosts several unrelated projects: a portfolio blog, a university group website, and a SaaS platform. I want:

• 
  Isolation: a memory leak in one project must not take down the others.


• 
  Resource quotas: each project gets a defined slice of the 8 GB RAM, enforced by the platform, not by hope.


• 
  Declarative deployments: the entire infrastructure lives in Git as YAML. If the server burns down, I can rebuild it in an hour.


• 
  One ingress to rule them all: a single reverse proxy routes all domains and handles all certificates.

Full Kubernetes (kubeadm) would eat half the server's resources just to run itself. K3s is a certified Kubernetes distribution by SUSE that fits in a ~512 MB memory footprint. Same API, same YAML, a fraction of the overhead. It is the sweet spot for a single-node setup.

What you need

• The hardened Ubuntu VPS from Part 1 (2 vCPU / 8 GB RAM or more recommended)


• A domain name with DNS you control


• 45 minutes

Before starting, create a DNS A record pointing a test subdomain to your server, for example:

whoami.yourdomain.com  →  YOUR_SERVER_IP

DNS propagation can take a few minutes, so doing it now means it will be ready when we need it in Step 6.

Step 1: Install Docker

K3s uses its own container runtime (containerd), so strictly speaking Docker is not required to run the cluster. We install it anyway, because it is invaluable for building images locally on the server and for quick debugging.

Use the official convenience script:

curl -fsSL https://get.docker.com | sudo sh

Add your user to the docker group so you can run it without sudo:

sudo usermod -aG docker $USER

newgrp docker

Verify:

docker run --rm hello-world

One important detail on a hardened server: Docker manipulates iptables directly and can bypass UFW rules when you publish ports with -p. Since all our public traffic will go through K3s and Traefik, avoid publishing Docker ports on this machine. If you ever need a quick test container, bind it to localhost only: -p 127.0.0.1:8080:80.

Step 2: Install K3s

One command, about thirty seconds:

curl -sfL https://get.k3s.io | sh -s - \

  --disable traefik \

  --write-kubeconfig-mode 644

Two flags deserve an explanation:

• 
  --disable traefik: K3s bundles Traefik, but we want to install and control our own Traefik v3 via Helm, with our own configuration. Letting K3s manage it means fighting its defaults later.


• 
  --write-kubeconfig-mode 644: makes the kubeconfig readable by non-root users, convenient on a single-user server. On a shared machine, skip this flag and copy the kubeconfig to your user manually.

Check that the node is ready:

kubectl get nodes

Expected output:

NAME        STATUS   ROLES                  AGE   VERSION

srv-xxxxx   Ready    control-plane,master   30s   v1.33.x+k3s1

Make kubectl work in every session by pointing it at the K3s kubeconfig:

echo 'export KUBECONFIG=/etc/rancher/k3s/k3s.yaml' >> ~/.bashrc

source ~/.bashrc

Step 3: Install Helm

Helm is the package manager for Kubernetes. We will use it to install Traefik and cert-manager with pinned, reproducible configurations.

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

helm version

Step 4: Install Traefik v3

Traefik is our front door: it receives all HTTP/HTTPS traffic on ports 80 and 443, routes requests to the right application based on the domain name, and terminates TLS.

Add the official Helm repository:

helm repo add traefik https://traefik.github.io/charts

helm repo update

Create a values file so the configuration lives in Git, not in your shell history:

mkdir -p ~/infra/traefik && nano ~/infra/traefik/values.yaml

# ~/infra/traefik/values.yaml

deployment:

  kind: Deployment

  replicas: 1



service:

  type: LoadBalancer   # K3s ships with ServiceLB (Klipper), this binds ports 80/443 on the node



ports:

  web:

    port: 8000

    exposedPort: 80

    redirections:

      entryPoint:

        to: websecure

        scheme: https

        permanent: true

  websecure:

    port: 8443

    exposedPort: 443

    tls:

      enabled: true



providers:

  kubernetesCRD:

    enabled: true

  kubernetesIngress:

    enabled: true



logs:

  general:

    level: INFO

  access:

    enabled: true



resources:

  requests:

    cpu: 100m

    memory: 128Mi

  limits:

    memory: 256Mi

The redirections block is doing quiet but important work: every HTTP request is permanently redirected to HTTPS at the entrypoint level, so no application ever needs to think about it.

Install into its own namespace:

kubectl create namespace traefik

helm install traefik traefik/traefik \

  --namespace traefik \

  --values ~/infra/traefik/values.yaml

Verify the pod is running and the ports are bound:

kubectl get pods -n traefik

kubectl get svc -n traefik

The service should show EXTERNAL-IP equal to your server's IP, with ports 80 and 443 mapped. At this point, visiting http://YOUR_SERVER_IP returns a 404 from Traefik — which is perfect: the front door is open, there is just nothing behind it yet.

Step 5: Install cert-manager

cert-manager automates the entire Let's Encrypt lifecycle: it requests certificates, answers the ACME challenges, stores the certs as Kubernetes secrets and renews them before expiry. Set it up once, never think about TLS again.

helm repo add jetstack https://charts.jetstack.io

helm repo update



helm install cert-manager jetstack/cert-manager \

  --namespace cert-manager \

  --create-namespace \

  --set crds.enabled=true

Wait for the three pods to be ready:

kubectl get pods -n cert-manager

Now define two ClusterIssuers: one for Let's Encrypt staging, one for production. Always test with staging first, because the production endpoint rate-limits you to 5 failed attempts per hour, and debugging DNS issues while rate-limited is a special kind of misery.

mkdir -p ~/infra/cert-manager && nano ~/infra/cert-manager/cluster-issuers.yaml

apiVersion: cert-manager.io/v1

kind: ClusterIssuer

metadata:

  name: letsencrypt-staging

spec:

  acme:

    server: https://acme-staging-v02.api.letsencrypt.org/directory

    email: [email protected]

    privateKeySecretRef:

      name: letsencrypt-staging-key

    solvers:

      - http01:

          ingress:

            class: traefik

---

apiVersion: cert-manager.io/v1

kind: ClusterIssuer

metadata:

  name: letsencrypt-prod

spec:

  acme:

    server: https://acme-v02.api.letsencrypt.org/directory

    email: [email protected]

    privateKeySecretRef:

      name: letsencrypt-prod-key

    solvers:

      - http01:

          ingress:

            class: traefik

Replace the email (Let's Encrypt uses it for expiry warnings) and apply:

kubectl apply -f ~/infra/cert-manager/cluster-issuers.yaml

kubectl get clusterissuers

Both issuers should show READY: True after a few seconds.

Step 6: Deploy a test app with automatic HTTPS

Time for the payoff. We deploy whoami, a tiny web server that echoes request information, and expose it over HTTPS on the subdomain you configured earlier.

mkdir -p ~/infra/apps && nano ~/infra/apps/whoami.yaml

apiVersion: v1

kind: Namespace

metadata:

  name: ns-test

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: whoami

  namespace: ns-test

spec:

  replicas: 1

  selector:

    matchLabels:

      app: whoami

  template:

    metadata:

      labels:

        app: whoami

    spec:

      containers:

        - name: whoami

          image: traefik/whoami:latest

          ports:

            - containerPort: 80

          resources:

            requests:

              cpu: 10m

              memory: 16Mi

            limits:

              memory: 32Mi

---

apiVersion: v1

kind: Service

metadata:

  name: whoami-svc

  namespace: ns-test

spec:

  selector:

    app: whoami

  ports:

    - port: 80

      targetPort: 80

---

apiVersion: cert-manager.io/v1

kind: Certificate

metadata:

  name: whoami-cert

  namespace: ns-test

spec:

  secretName: whoami-tls

  issuerRef:

    name: letsencrypt-prod

    kind: ClusterIssuer

  dnsNames:

    - whoami.yourdomain.com

---

apiVersion: traefik.io/v1alpha1

kind: IngressRoute

metadata:

  name: whoami-route

  namespace: ns-test

spec:

  entryPoints:

    - websecure

  routes:

    - match: Host(`whoami.yourdomain.com`)

      kind: Rule

      services:

        - name: whoami-svc

          port: 80

  tls:

    secretName: whoami-tls

Replace whoami.yourdomain.com with your actual subdomain (twice), then:

kubectl apply -f ~/infra/apps/whoami.yaml

Watch the certificate being issued:

kubectl get certificate -n ns-test -w

Within a minute, READY flips to True. Now open https://whoami.yourdomain.com in your browser: a valid Let's Encrypt certificate, automatic HTTP→HTTPS redirect, and the whoami output showing your request went through Traefik.

Take a second to appreciate what just happened: you wrote one YAML file, and the platform handled deployment, routing, certificate issuance and TLS termination. Every future application follows the exact same pattern.

If the certificate stays stuck in READY: False, the usual suspects are:

# Check the ACME challenge status

kubectl describe certificaterequest -n ns-test

kubectl get challenges -n ns-test

Nine times out of ten it is DNS: the A record has not propagated yet, or points to the wrong IP. Verify with dig whoami.yourdomain.com +short.

Final checklist

# 1. K3s node ready

kubectl get nodes

# Expected: STATUS Ready



# 2. Traefik running and bound to 80/443

kubectl get svc -n traefik

# Expected: EXTERNAL-IP = your server IP, ports 80/443



# 3. ClusterIssuers ready

kubectl get clusterissuers

# Expected: both READY True



# 4. Test app serving valid HTTPS

curl -sI https://whoami.yourdomain.com | head -1

# Expected: HTTP/2 200



# 5. HTTP redirects to HTTPS

curl -sI http://whoami.yourdomain.com | grep -i location

# Expected: location: https://whoami.yourdomain.com/

Once everything passes, clean up the test app if you like:

kubectl delete -f ~/infra/apps/whoami.yaml

What's next

We now have a hardened server running a Kubernetes platform with automatic HTTPS. In Part 3, we make it truly multi-tenant: one namespace per project with enforced resource quotas, a shared PostgreSQL and Redis for the small projects, and Traefik middlewares for security headers, rate limiting and CORS. That is where the "several unrelated projects on one 8 GB server without them stepping on each other" promise gets fulfilled.

Questions or suggestions? Reach out, I answer everything. If your certificate refuses to issue and you have already sacrificed a rubber duck to the DNS gods, send me the output of kubectl get challenges and we will figure it out.