Skip to main content

Deploy your first app

Inspect 1.36

With a healthy cluster confirmed, deploy a sample application to it and open it in your browser through a Hetzner Load Balancer. Most of the wait is the load balancer coming up.

Prerequisites

  • A healthy workload cluster with KUBECONFIG still pointed at it. Complete to confirm it is ready.

Deploy the application

You create two Kubernetes objects. A Deployment keeps a set of identical pods running and replaces any that fail. A Service gives those pods one stable address; with type: LoadBalancer, that address is a public IP on a Hetzner Load Balancer.

Create a file named app.yaml:

yaml
		# app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: hello
          image: nginx:stable-alpine
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  type: LoadBalancer
  selector:
    app: hello
  ports:
    - port: 80
      targetPort: 80

Apply it:

		$ kubectl apply -f app.yaml
deployment.apps/hello created
service/hello created

Both pods start within a few seconds. Confirm they are running:

		$ kubectl get pods -l app=hello
NAME                     READY   STATUS    RESTARTS   AGE
hello-6d4b9c8f7d-8kx2p   1/1     Running   0          20s
hello-6d4b9c8f7d-v5qtm   1/1     Running   0          20s

Both pods show 1/1 Running. The random suffixes in your pod names differ.

Watch the load balancer appear

A Service with type: LoadBalancer tells Syself Autopilot to create a Hetzner Load Balancer in the Hetzner Cloud project that holds your cluster. This takes about a minute. Once it exists, every request follows the same path:

flowchart LR
  I["Internet<br/>the external IP"] --> LB["Hetzner Load Balancer"] --> S["Service<br/>hello"] --> P["Pods<br/>your app replicas"]

Watch the Service until an external IP appears:

		$ kubectl get service hello --watch
NAME    TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
hello   LoadBalancer   100.96.45.12   <pending>     80:31820/TCP   15s
hello   LoadBalancer   100.96.45.12   167.235.10.20 80:31820/TCP   70s

When the EXTERNAL-IP column changes from <pending> to an IP address, the load balancer is ready. Press Ctrl+ C to stop watching. Your IP and ports differ from the example.

You can also see the new load balancer in the Hetzner Cloud Console⁠ under Load Balancers.

Access the application

Open http://<EXTERNAL-IP> in your browser, or test it with curl:

		$ curl http://<EXTERNAL-IP>

You should see the nginx welcome page, an HTML response starting with <title>Welcome to nginx!</title>. Your app is live on the internet. Both pods serve traffic through the same load balancer, so if one fails, the other keeps answering.

Clean up

Delete the Deployment and Service when you are done:

		$ kubectl delete -f app.yaml
deployment.apps "hello" deleted
service "hello" deleted

The Hetzner Load Balancer is deleted automatically when the Service is removed, so it stops billing right away.

Beyond a single load balancer

This example uses a plain LoadBalancer Service, one load balancer per application. For production workloads you typically want:

  • An ingress controller. This is a component that routes requests for several applications through one load balancer, based on the hostname or URL path. Syself Autopilot does not include a built-in ingress controller; choose one that fits your needs.
  • TLS termination at the ingress level.

See for a complete guide covering ingress and TLS options.

Get the most out of Syself

You now have a running cluster and a working deploy loop. That is the demo. The platform's depth shows up in what comes next:

  • Run a production-ready workload. Syself Autopilot drains and replaces nodes during upgrades and self-healing. A bare Deployment like the one above takes a traffic hit on every such event. adds the probes, disruption budgets, and resource requests that keep an app serving through all of it.
  • Harden your workloads. The node this app ran on is hardened by default. The pod you deployed is not. covers the security checklist to work through before production.
  • Set up observability. Every component in the cluster exports Prometheus metrics, but nothing collects them yet. turns them into dashboards and alerts.
  • Bring in your team. So far you have used a single kubeconfig file. connects your identity provider so teammates log in with short-lived tokens instead of shared credentials.
Tip

GitOps is a natural next step. You can keep every manifest in a Git repository and use Argo CD or Flux to apply changes automatically. See .

Next step

You have a running app and a working deploy loop. Continue with to see where to go from here: understanding the platform, upgrades, security, and running real services.

Related

Explore your cluster

Run essential kubectl commands to inspect your Syself Autopilot cluster. Learn what healthy nodes, system pods, and events look like on a fresh cluster.

Next steps

Where to go after deploying your first app on Syself Autopilot: understand the platform, plan for upgrades, work through the security checklist, and run real services.