DEV Community: Sanskriti Harmukh

Deploying Kubernetes Dashboard and Managing Cluster Resources

Sanskriti Harmukh — Fri, 24 Jul 2026 14:19:09 +0000

Kubernetes Dashboard is an open-source web GUI for managing cluster resources (CronJobs, DaemonSets, Deployments, Pods, ReplicaSets, StatefulSets) deploying apps, and monitoring cluster health in real time. This guide installs it via Helm, sets up admin and read-only RBAC access, secures it behind Nginx Ingress with cert-manager TLS, and deploys a sample app from the UI.

Prerequisites: a Kubernetes cluster with kubectl configured, and Helm installed on your workstation.

Install the Dashboard

$ helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
$ helm repo update
$ helm install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard
$ kubectl get all -n kubernetes-dashboard

Confirm pods, services, and replicasets are up.

Configure Access

The Dashboard authenticates via bearer tokens tied to a ServiceAccount.

1. Create an admin service account:

$ nano dashboard-admin-user.yml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dashboard-admin-user
  namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dashboard-admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: dashboard-admin-user
  namespace: kubernetes-dashboard

This binds to cluster-admin — full control over the cluster. Use a scoped Role/ClusterRole instead for production.

$ kubectl apply -f dashboard-admin-user.yml
$ kubectl -n kubernetes-dashboard create token dashboard-admin-user

Save the printed token — you'll use it to log in.

2. Optional — a read-only user for monitoring-only access:

$ nano read-only-user.yml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: read-only-user
  namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: read-only-clusterrole
rules:
- apiGroups: ["", "apps", "extensions"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-only-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: read-only-clusterrole
subjects:
- kind: ServiceAccount
  name: read-only-user
  namespace: kubernetes-dashboard

$ kubectl apply -f read-only-user.yml
$ kubectl -n kubernetes-dashboard create token read-only-user

Access via Port Forwarding

1. Forward the Dashboard's HTTPS endpoint:

$ kubectl port-forward service/kubernetes-dashboard-kong-proxy 8443:443 -n kubernetes-dashboard

2. On a remote workstation, open the firewall and bind to all interfaces:

$ sudo ufw allow 8443/tcp
$ sudo ufw reload
$ kubectl port-forward service/kubernetes-dashboard-kong-proxy 8443:443 -n kubernetes-dashboard --address='0.0.0.0'

3. Visit https://127.0.0.1:8443 (or https://<server-ip>:8443), accept the self-signed cert warning, paste your admin token, and sign in. From the UI you can switch namespaces (top nav) and check Nodes under Cluster for resource usage.

Secure It with Ingress + TLS

Exposing the Dashboard on a public endpoint via --address=0.0.0.0 is fine for testing but not production — put it behind Ingress with a real TLS certificate instead.

1. Stop port forwarding (Ctrl+C), then install Nginx Ingress:

$ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
$ helm repo update
$ helm install ingress-nginx ingress-nginx/ingress-nginx \
--namespace ingress-nginx \
--create-namespace
$ kubectl get services -n ingress-nginx

Point your domain's DNS at the resulting EXTERNAL-IP.

2. Install cert-manager:

$ 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
$ kubectl get all -n cert-manager

3. Create a ClusterIssuer:

$ nano issuer.yml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: tls-certificate-issuer
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-private-key
    solvers:
      - http01:
          ingress:
            ingressClassName: nginx

$ kubectl apply -f issuer.yml
$ kubectl get clusterissuer

4. Patch the Ingress controller so cert-manager's HTTP-01 challenge isn't blocked by strict path validation:

$ kubectl patch configmap ingress-nginx-controller -n ingress-nginx --patch '{"data":{"strict-validate-path-type":"false"}}'

5. Create the Dashboard Ingress. Replace dashboard.example.com:

$ nano dashboard-ingress.yml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kubernetes-dashboard-ingress
  namespace: kubernetes-dashboard
  annotations:
    cert-manager.io/cluster-issuer: tls-certificate-issuer
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - dashboard.example.com
      secretName: kubernetes-dashboard-cert
  rules:
    - host: dashboard.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: kubernetes-dashboard-kong-proxy
                port:
                  number: 443

$ kubectl apply -f dashboard-ingress.yml
$ kubectl get certificate -n kubernetes-dashboard
$ kubectl get ingress -n kubernetes-dashboard

Visit https://dashboard.example.com once the certificate flips to True.

Deploy an App from the Dashboard

1. Point a subdomain (e.g. sample-app.example.com) at the Ingress controller's external IP.

2. In the Dashboard, click + → Create from form:

App name: sample-app
Container Image: nginxdemos/hello
Service: Internal, port 80, target port 80
Namespace: default

Click Deploy, then check Workloads → Pods and Services to confirm it's running.

3. Add an Ingress via Create from input:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: sample-app-ingress
  annotations:
    cert-manager.io/cluster-issuer: tls-certificate-issuer
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - sample-app.example.com
      secretName: sample-app-cert
  rules:
    - host: sample-app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: sample-app
                port:
                  number: 80

Upload it, confirm it under Ingresses, then visit https://sample-app.example.com. You should see the sample app, with Auto Refresh showing traffic load-balanced across pods.

Next Steps

Kubernetes Dashboard is running with RBAC-scoped access and TLS via Ingress. From here:

Swap the cluster-admin binding for a scoped role once you've validated the workflow
Use the read-only token for team members who only need visibility
Deploy production workloads through the same Ingress + cert-manager pattern established here

For the full guide, visit the original article on Vultr Docs.

Deploying Strapi on a Kubernetes Cluster

Sanskriti Harmukh — Fri, 24 Jul 2026 14:17:45 +0000

Strapi is a headless CMS with an intuitive admin dashboard, custom content types, and role-based permissions, well-suited to Kubernetes for its scalability and multi-environment support. This guide builds a Strapi app, containerizes it, and deploys it to Kubernetes behind an Nginx Ingress Controller with cert-manager TLS.

Prerequisites: a Kubernetes cluster with kubectl/helm configured, a PostgreSQL database, Docker on your workstation, a domain (this guide uses strapi.example.com) pointed at the ingress load balancer once provisioned.

Build the Strapi Application

1. Install Node.js:

$ curl -sL https://deb.nodesource.com/setup_22.x | sudo -E bash -
$ sudo apt install -y nodejs

2. Configure Git if not already set up:

$ git config --global user.name "Your Full Name"
$ git config --global user.email "email@example.com"

3. Scaffold a project:

$ npx create-strapi-app@latest strapi-project --quickstart --js

Once it's running, press Ctrl+C to stop the dev server and continue configuring it.

Containerize the Application

1. Point it at PostgreSQL — edit .env in the project directory:

$ cd strapi-project
$ nano .env

DATABASE_CLIENT=postgres
DATABASE_HOST=your-db-host
DATABASE_PORT=5432
DATABASE_NAME=strapi_db
DATABASE_USERNAME=user
DATABASE_PASSWORD=password
DATABASE_SSL=true
DATABASE_SSL_REJECT_UNAUTHORIZED=false
DATABASE_SCHEMA=public
DATABASE_CONNECTION_TIMEOUT=60000

2. Replace config/server.js:

$ mv config/server.js config/server.ORIG
$ nano config/server.js

module.exports = ({ env }) => ({
  host: env('HOST', '0.0.0.0'),
  port: env.int('PORT', 1337),
  url: env('STRAPI_URL'),
  app: {
    keys: env.array('APP_KEYS'),
  },
  webhooks: {
    populateRelations: env.bool('WEBHOOKS_POPULATE_RELATIONS', false),
  },
});

3. Set the URL, install the PostgreSQL driver, rebuild, run:

$ export STRAPI_URL="http://127.0.0.1:1337"
$ npm install pg --save
$ npm run build
$ npm run start &

Visit http://<server-ip>:1337 and confirm the admin registration screen loads.

Build and Push the Docker Image

1. Dockerfile:

$ nano Dockerfile

FROM node:22-alpine

RUN apk update && apk add --no-cache build-base gcc autoconf automake zlib-dev libpng-dev nasm bash vips-dev
ARG NODE_ENV=production
ENV NODE_ENV=${NODE_ENV}

WORKDIR /opt/
COPY package.json package-lock.json ./
RUN npm install
ENV PATH=/opt/node_modules/.bin:$PATH

WORKDIR /opt/app
COPY . .
RUN chown -R node:node /opt/app
USER node
RUN ["npm", "run", "build"]

EXPOSE 1337

CMD ["npm", "run", "start"]

2. .dockerignore:

$ nano .dockerignore

node_modules/

3. Build, tag, push:

$ docker build -t strapi:latest .
$ docker login -u <username> -p <password>
$ docker tag strapi:latest <username>/strapi:latest
$ docker push <username>/strapi:latest

Prepare the Cluster

Install the Nginx Ingress Controller

$ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
$ helm repo update
$ kubectl create namespace ingress-nginx
$ helm install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress-nginx

A LoadBalancer provisions automatically:

$ kubectl get services ingress-nginx-controller --namespace ingress-nginx

It may take a few minutes for EXTERNAL-IP to populate.

Install cert-manager and a ClusterIssuer

$ kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.17.2/cert-manager.yaml

Point your domain's A record at the Ingress controller's EXTERNAL-IP, then:

$ nano clusterissuer.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: "hello@example.com"
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
      - http01:
          ingress:
            class: nginx

$ kubectl apply -f clusterissuer.yaml
$ kubectl get clusterissuer letsencrypt-prod

READY: True confirms it's live.

Deploy Strapi

1. Deployment (2 replicas):

$ nano strapi-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: strapi-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      name: strapi-app
  template:
    metadata:
      labels:
        name: strapi-app
    spec:
      imagePullSecrets:
        - name: regcred
      containers:
        - name: strapi
          image: <username>/strapi:latest
          imagePullPolicy: Always
          command: ["sh", "-c", "npm run build && npm run start"]
          ports:
            - containerPort: 1337
          env:
            - name: STRAPI_URL
              value: "strapi.example.com"

regcred is a pull secret if your image lives in a private registry.

$ kubectl apply -f strapi-deployment.yaml
$ kubectl get deployment strapi-deployment

2. Service:

$ nano strapi-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: strapi-service
spec:
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 1337
  selector:
    name: strapi-app

$ kubectl apply -f strapi-service.yaml

3. Ingress with TLS:

$ nano strapi-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: strapi-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - secretName: strapi-tls
      hosts:
        - strapi.example.com
  rules:
    - host: strapi.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: strapi-service
                port:
                  number: 80

$ kubectl apply -f strapi-ingress.yaml
$ kubectl get ingress

Visit https://strapi.example.com — you should hit the login page over HTTPS.

Scale the Deployment

$ kubectl scale deployment/strapi-deployment --replicas=4
$ kubectl get deployment strapi-deployment
$ kubectl get pods

Scale back down:

$ kubectl scale deployment/strapi-deployment --replicas=2

Test fault tolerance by deleting a pod. Kubernetes replaces it and the Ingress routes around the gap with no downtime:

$ kubectl delete pod <pod-name>

Next Steps

Strapi is running on Kubernetes with TLS termination and horizontal scaling. From here:

Add a HorizontalPodAutoscaler to scale on CPU/memory instead of manually
Move media uploads to S3-compatible object storage via a Strapi upload provider plugin
Set resource requests/limits on the Deployment to avoid noisy-neighbor scheduling issues

For the full guide, visit the original article on Vultr Docs.

Deploying MariaDB on Kubernetes

Sanskriti Harmukh — Fri, 24 Jul 2026 14:16:12 +0000

MariaDB is a popular open-source relational database. Running it on Kubernetes gets you portability across environments, CI/CD integration, and automated backup/recovery alongside the usual scalability and high-availability benefits. This guide sets up persistent storage, deploys MariaDB as a StatefulSet, exposes it via a Service, and covers scaling.

Prerequisites: a Kubernetes cluster with at least 3 nodes and kubectl configured against it.

Create Persistent Volume and Claim

1. Define a PersistentVolume:

$ nano mariadb-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
    name: mariadb-pv
spec:
    capacity:
        storage: 10Gi
    accessModes:
        - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain
    hostPath:
        path: /mnt/data/mariadb

Retain keeps the data if the PV is deleted; hostPath backs it with a directory on the node.

$ kubectl apply -f mariadb-pv.yaml
$ kubectl get pv mariadb-pv

2. Define a matching PersistentVolumeClaim:

$ nano mariadb-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: mariadb-pvc
spec:
    accessModes:
        - ReadWriteOnce
    resources:
        requests:
            storage: 10Gi

$ kubectl apply -f mariadb-pvc.yaml
$ kubectl get pvc mariadb-pvc

Confirm status is Bound before continuing.

Deploy the MariaDB StatefulSet

1. Create a ConfigMap for my.cnf:

$ nano mariadb-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
    name: mariadb-config
data:
    my.cnf: |
        [mysqld]
        bind-address=0.0.0.0
        default_storage_engine=InnoDB
        innodb_file_per_table=1
        max_connections=1000

$ kubectl apply -f mariadb-config.yaml

2. Create the StatefulSet. Replace strong_password:

$ nano mariadb-statefulset.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mariadb
spec:
  serviceName: "mariadb"
  replicas: 1
  selector:
    matchLabels:
      app: mariadb
  template:
    metadata:
      labels:
        app: mariadb
    spec:
      containers:
        - name: mariadb
          image: mariadb:latest
          ports:
            - containerPort: 3306
              name: mariadb
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: "strong_password"
          volumeMounts:
            - name: mariadb-storage
              mountPath: /var/lib/mysql
            - name: config-volume
              mountPath: /etc/mysql/conf.d
      volumes:
        - name: config-volume
          configMap:
            name: mariadb-config
  volumeClaimTemplates:
    - metadata:
        name: mariadb-storage
      spec:
        accessModes: [ "ReadWriteOnce" ]
        resources:
          requests:
            storage: 10Gi

$ kubectl apply -f mariadb-statefulset.yaml
$ kubectl get statefulset mariadb
$ kubectl get pods -l app=mariadb

Access MariaDB

1. Expose it internally:

$ nano mariadb-service.yaml

apiVersion: v1
kind: Service
metadata:
    name: mariadb
spec:
    ports:
    - port: 3306
      targetPort: 3306
    selector:
        app: mariadb

$ kubectl apply -f mariadb-service.yaml
$ kubectl get svc mariadb

2. Connect with a throwaway client pod:

$ kubectl run -it --rm --image=mysql:latest --restart=Never mysql-client -- mysql -h mariadb -u root -pstrong_password

mysql> show databases;
mysql> exit;

Scale the Deployment

$ kubectl scale statefulset mariadb --replicas=3
$ kubectl get statefulset mariadb
$ kubectl get pods -l app=mariadb

Scale back down:

$ kubectl scale statefulset mariadb --replicas=2

Each replica in this setup is an independent MariaDB instance with its own PVC — for real multi-node replication, layer in MariaDB Galera or MaxScale rather than relying on StatefulSet scaling alone.

Next Steps

MariaDB is running on Kubernetes with persistent storage and a scalable StatefulSet. From here:

Swap the hostPath PV for a CSI-backed StorageClass in production so pods can reschedule across nodes
Add readiness/liveness probes on port 3306 for better failure detection
Front the service with an external LoadBalancer or Ingress if clients outside the cluster need access

For the full guide, visit the original article on Vultr Docs.

Deploying CockroachDB on Kubernetes

Sanskriti Harmukh — Fri, 24 Jul 2026 14:15:31 +0000

CockroachDB is a distributed SQL database that replicates data across nodes for high availability. If a node fails, the cluster elects new nodes and rebalances automatically, and an automated repair feature detects and corrects data inconsistencies. This guide deploys CockroachDB on Kubernetes via the CockroachDB Operator, and covers access through both the SQL client and the graphical console.

Prerequisites: a Kubernetes cluster with at least 3 nodes, 8GB RAM and 4 vCPUs each, and a workstation with kubectl configured against the cluster.

Install the CockroachDB Operator

The operator automates scaling and maintenance of CockroachDB nodes.

$ kubectl apply -f https://raw.githubusercontent.com/cockroachdb/cockroach-operator/v2.12.0/install/crds.yaml
$ kubectl apply -f https://raw.githubusercontent.com/cockroachdb/cockroach-operator/v2.12.0/install/operator.yaml

Check the operator tags page for the latest version before installing.

Wait ~2 minutes, then verify:

$ kubectl get pods -n cockroach-operator-system

You should see cockroach-operator-manager-* running.

Create a CockroachDB Cluster

Production minimums: a PVC-backed volume of at least 60GB, 2 vCPUs, 8GB memory per node.

$ mkdir cockroachdb-cluster
$ cd cockroachdb-cluster
$ nano cluster.yaml

apiVersion: crdb.cockroachlabs.com/v1alpha1
kind: CrdbCluster
metadata:
  name: cockroachdb
spec:
  dataStore:
    pvc:
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: "60Gi"
        volumeMode: Filesystem
  resources:
    requests:
      cpu: 2
      memory: 4Gi
    limits:
      cpu: 2
      memory: 8Gi
  tlsEnabled: true
  image:
    name: cockroachdb/cockroach:v23.1.11
  nodes: 3
  additionalLabels:
    crdb: cockroachdb-cluster

$ kubectl apply -f cluster.yaml

Wait ~3 minutes for the cluster and its backing volumes to provision, then verify:

$ kubectl get crdbcluster
$ kubectl get pods

You should see cockroachdb-0, cockroachdb-1, cockroachdb-2 all Running.

Access the Cluster

CockroachDB is reachable internally via the cockroachdb-public service.

1. Check services:

$ kubectl get svc

2. Deploy a secure SQL client pod:

$ kubectl create -f https://raw.githubusercontent.com/cockroachdb/cockroach-operator/v2.12.0/examples/client-secure-operator.yaml
$ kubectl get pods

3. Open a SQL shell against the cluster:

$ kubectl exec -it cockroachdb-client-secure -- ./cockroach sql --certs-dir=/cockroach/cockroach-certs --host=cockroachdb-public

4. Create a database and admin user:

> CREATE DATABASE exampledb;
> CREATE USER example_admin WITH PASSWORD 'strong-pass';
> GRANT admin TO example_admin;
> \q

5. Expose the graphical console via a LoadBalancer:

$ kubectl expose service cockroachdb-public --type=LoadBalancer --name=cockroachdb-external

Wait a few minutes for an external IP, then:

$ kubectl get svc

6. Open the console at https://<external-ip>:8080 and log in with example_admin. From there you can inspect cluster status, nodes, and databases.

Next Steps

CockroachDB is running as a 3-node cluster with TLS enabled and both SQL and console access. From here:

Scale nodes in the cluster spec to add capacity
Set up automated backups to object storage via BACKUP scheduled jobs
Point application connection strings at cockroachdb-public for in-cluster access, or the LoadBalancer IP for external clients

For the full guide, visit the original article on Vultr Docs.

Deploying Apache Cassandra on Kubernetes

Sanskriti Harmukh — Fri, 24 Jul 2026 14:14:55 +0000

Apache Cassandra is a highly scalable, distributed NoSQL database built for write-heavy workloads, horizontal scaling, and tunable consistency, with no single point of failure. K8ssandra is an open-source operator that automates Cassandra provisioning, scaling, backups, and repairs on Kubernetes. This guide deploys a multi-node Cassandra cluster via the K8ssandra Operator, with cert-manager, persistent block storage, and a LoadBalancer service for external access.

Prerequisites: a Kubernetes cluster with at least 4 nodes / 4GB RAM each, a workstation with kubectl and helm configured against the cluster.

Install `cqlsh`

cqlsh is the Python-based CLI for querying Cassandra.

$ sudo apt update
$ sudo apt install -y python3 python3-pip python3.12-venv
$ python3 -m venv cassandra
$ source cassandra/bin/activate
$ pip install -U cqlsh
$ cqlsh --version

Install cert-manager

K8ssandra uses cert-manager to generate the Java keystores/truststores Cassandra needs for internal TLS.

$ 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
$ kubectl get all -n cert-manager

Install the K8ssandra Operator

$ helm repo add k8ssandra https://helm.k8ssandra.io/stable
$ helm install k8ssandra-operator k8ssandra/k8ssandra-operator \
  --namespace k8ssandra-operator \
  --create-namespace
$ kubectl -n k8ssandra-operator get deployment
$ kubectl get pods -n k8ssandra-operator

You should see both k8ssandra-operator and k8ssandra-operator-cass-operator deployments ready.

Deploy a Multi-Node Cassandra Cluster

1. Check available StorageClasses in your cluster:

$ kubectl get storageclass

Note the name of a CSI-backed block storage class — you'll reference it below.

2. Create the cluster manifest:

$ nano cluster.yaml

apiVersion: k8ssandra.io/v1alpha1
kind: K8ssandraCluster
metadata:
  name: demo
spec:
  cassandra:
    serverVersion: "4.0.1"
    datacenters:
      - metadata:
          name: dc1
        size: 3
        storageConfig:
          cassandraDataVolumeClaimSpec:
            storageClassName: standard
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 10Gi
        config:
          jvmOptions:
            heapSize: 512M
        stargate:
          size: 1
          heapSize: 256M

Replace standard with your cluster's actual StorageClass name. This provisions 3 Cassandra nodes with a 10GB volume each, 512MB JVM heap per Cassandra node, and a single Stargate node (REST/GraphQL/Document API gateway in front of Cassandra) with a 256MB heap. Confirm your cloud provider's CSI driver is installed and configured before applying — it's required for dynamic volume provisioning.

3. Apply and wait (cluster bring-up takes ~15 minutes):

$ kubectl apply -n k8ssandra-operator -f cluster.yaml
$ kubectl get pods -n k8ssandra-operator --watch

You're looking for 3 demo-dc1-default-sts-N pods and a demo-dc1-default-stargate-deployment-* pod, all Running.

Verify Persistent Storage

Cassandra nodes run as a StatefulSet, each backed by a PVC for durable storage.

$ kubectl get statefulset -n k8ssandra-operator
$ kubectl get sc standard
$ kubectl get pvc --all-namespaces

All three PVCs should show Bound.

Expose the Cluster

Create a LoadBalancer service to reach Cassandra over the native CQL protocol (port 9042):

$ nano service.yaml

apiVersion: v1
kind: Service
metadata:
  name: cassandra
  labels:
    app: cassandra
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
    - port: 9042
      targetPort: 9042
  selector:
    app.kubernetes.io/name: cassandra

$ kubectl apply -n k8ssandra-operator -f service.yaml
$ kubectl get svc/cassandra -n k8ssandra-operator

Wait for EXTERNAL-IP to populate (a few minutes) — that's your connection address.

Test the Cluster

$ CASS_IP=$(kubectl get svc cassandra -n k8ssandra-operator -o jsonpath="{.status.loadBalancer.ingress[*].ip}")
$ CASS_USERNAME=$(kubectl get secret demo-superuser -n k8ssandra-operator -o=jsonpath='{.data.username}' | base64 --decode)
$ CASS_PASSWORD=$(kubectl get secret demo-superuser -n k8ssandra-operator -o=jsonpath='{.data.password}' | base64 --decode)
$ cqlsh -u $CASS_USERNAME -p $CASS_PASSWORD $CASS_IP 9042

demo-superuser@cqlsh> CREATE KEYSPACE demo WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3};
demo-superuser@cqlsh> CREATE TABLE demo.users (id text primary key, name text, country text);
demo-superuser@cqlsh> BEGIN BATCH
                         INSERT INTO demo.users (id, name, country) VALUES ('42', 'John Doe', 'UK');
                         INSERT INTO demo.users (id, name, country) VALUES ('43', 'Joe Smith', 'US');
                      APPLY BATCH;
demo-superuser@cqlsh> SELECT * FROM demo.users;

 id | country | name
----+---------+-----------
 43 |      US | Joe Smith
 42 |      UK |  John Doe

(2 rows)

Next Steps

Cassandra is running as a 3-node cluster with persistent storage and a Stargate data gateway. From here:

Scale size in the datacenter spec and reapply to add nodes
Enable Stargate's REST/GraphQL APIs for app access without a native CQL driver
Configure K8ssandra's Medusa integration for scheduled backups to object storage

For the full guide, visit the original article on Vultr Docs.

Deploying Gateway API with TLS Encryption on Kubernetes

Sanskriti Harmukh — Fri, 24 Jul 2026 14:12:45 +0000

The Kubernetes Gateway API is the successor to Ingress, a more expressive, role-oriented resource model (GatewayClass, Gateway, HTTPRoute) for advanced traffic routing and cross-namespace connectivity. This guide installs Envoy Gateway as the controller, configures cert-manager for automated Let's Encrypt TLS, and routes HTTPS traffic to a sample app.

Prerequisites: a Kubernetes cluster, kubectl and helm configured against it, and a domain name (e.g. app.example.com).

Install Envoy Gateway

Envoy Gateway translates Gateway API resources into Envoy Proxy configuration.

1. Install the CRDs and controller:

$ helm install eg oci://docker.io/envoyproxy/gateway-helm --version v1.6.1 -n envoy-gateway-system --create-namespace
$ kubectl wait --timeout=5m -n envoy-gateway-system deployment/envoy-gateway --for=condition=Available

2. Register a GatewayClass:

$ kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eg
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
EOF

Install cert-manager

Deploy cert-manager with the Gateway API feature gate on, so it can route Let's Encrypt HTTP-01 validation traffic through the Gateway.

$ helm upgrade --install cert-manager oci://quay.io/jetstack/charts/cert-manager \
    --namespace cert-manager \
    --create-namespace \
    --version v1.19.2 \
    --set config.apiVersion=controller.config.cert-manager.io/v1alpha1 \
    --set config.kind=ControllerConfiguration \
    --set config.enableGatewayAPI=true \
    --set crds.enabled=true
$ kubectl wait --for=condition=Ready pods --all -n cert-manager

Configure a ClusterIssuer

Registers the cluster with Let's Encrypt so it can issue certificates cluster-wide, using the HTTP-01 solver via the Gateway.

$ nano cluster-issuer.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
      - http01:
          gatewayHTTPRoute:
            parentRefs:
              - name: web-gateway
                kind: Gateway

$ kubectl apply -f cluster-issuer.yaml

Deploy a Sample App

$ kubectl create deployment web-app --image=nginxdemos/hello --replicas=2
$ kubectl expose deployment web-app --port=80 --target-port=80

Initialize the Gateway

The Gateway resource provisions a cloud LoadBalancer and public IP, and defines HTTP/HTTPS listeners for your domain.

$ nano gateway.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gateway
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  gatewayClassName: eg
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: "app.example.com"
      allowedRoutes:
        namespaces:
          from: Same
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "app.example.com"
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: web-app-tls-secret
      allowedRoutes:
        namespaces:
          from: Same

$ kubectl apply -f gateway.yaml
$ kubectl get gateway web-gateway

Point your domain's DNS A record at the returned external IP, then check the certificate:

$ kubectl get certificate

It may take a few minutes to flip to True.

Configure Secure Routing

Attach an HTTPRoute to the HTTPS listener only, so the app is unreachable over plain HTTP.

$ nano http-route.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-app-route
spec:
  parentRefs:
    - name: web-gateway
      sectionName: https
  hostnames:
    - "app.example.com"
  rules:
    - backendRefs:
        - name: web-app
          port: 80

$ kubectl apply -f http-route.yaml

Visit https://app.example.com. You should see a valid-certificate padlock and the sample app.

Next Steps

Envoy Gateway is routing HTTPS traffic via the Gateway API, with cert-manager handling certificate lifecycle automatically. From here:

Add more HTTPRoute rules for path/header-based routing to additional backends
Move the ClusterIssuer to the Let's Encrypt staging endpoint while testing to avoid rate limits
Explore GRPCRoute and TCPRoute for non-HTTP traffic through the same Gateway

For the full guide, visit the original article on Vultr Docs.

Deploying Large Language Models (LLMs) with Ollama

Sanskriti Harmukh — Fri, 24 Jul 2026 14:09:38 +0000

Ollama is an open-source platform for running large language models locally (Llama 3, DeepSeek R1, Mistral, Phi-4, Gemma 2, and more) with no internet connection or cloud API required. Running models locally improves privacy, security, and gives you full control over performance tuning. This guide installs Ollama on Linux/macOS/Windows, downloads and runs models, and covers management and environment-variable configuration.

Install Ollama

Linux

1. Install via the official script:

$ curl -fsSL https://ollama.com/install.sh | sh

2. Verify and list models:

$ ollama -v
$ ollama list

3. Ollama installs as a systemd service — check it, enable at boot, restart:

$ sudo systemctl status ollama
$ sudo systemctl enable ollama
$ sudo systemctl restart ollama

Optional — AMD GPU (ROCm) support:

$ curl -L https://ollama.com/download/ollama-linux-amd64-rocm.tgz -o ollama-linux-amd64-rocm.tgz
$ sudo tar -C /usr/ -xzf ollama-linux-amd64-rocm.tgz

macOS

Download the package from ollama.com/download, open the .zip, drag Ollama.app to Applications.
Verify and start:

$ ollama -v
$ ollama list
$ ollama serve

Windows

Download the .exe from ollama.com/download/windows and run the installer.
From PowerShell:

> ollama -v
> ollama list
> ollama serve

Download Models

1. Pull a model by name:

$ ollama pull [model]

2. Examples:

$ ollama pull mistral
$ ollama pull deepseek-r1:1.5b
$ ollama pull llama3.3

Llama 3.3 is ~40GB — confirm you have the disk space before pulling.

3. List what's local:

$ ollama list

NAME                ID              SIZE      MODIFIED
llama3.3:latest     a6eb4748fd29    42 GB     21 seconds ago
deepseek-r1:1.5b    a42b25d8c10a    1.1 GB    4 minutes ago
mistral:latest      f974a74358d6    4.1 GB    26 minutes ago

Run Models

1. Run a model directly:

$ ollama run qwen2.5:1.5b

2. Enter a prompt at the >>> interactive prompt:

>>> Give me two lines of text about cloud computing

The model streams its response in the terminal. Exit with /bye.

3. Run a reasoning model like DeepSeek R1 — its output includes a <think> block showing its reasoning trace before the final answer:

$ ollama run deepseek-r1:1.5b

Different models suit different tasks — run several against the same prompt to compare quality and speed on your hardware.

Manage Models

$ ollama list                        # list local models
$ ollama show llama3.3                # inspect a model's params, context length, license
$ ollama stop deepseek-r1:1.5b        # stop a running model
$ ollama rm mistral                   # remove a model

Environment Variables

Key variables:

OLLAMA_HOST — server bind address
OLLAMA_GPU_OVERHEAD — reserved VRAM per GPU (bytes)
OLLAMA_MODELS — custom model storage directory
OLLAMA_KEEP_ALIVE — how long a model stays loaded in memory
OLLAMA_DEBUG — verbose logging
OLLAMA_FLASH_ATTENTION — experimental attention optimizations
OLLAMA_NOHISTORY — disable readline history
OLLAMA_NOPRUNE — skip blob pruning at startup
OLLAMA_ORIGINS — allowed origin URLs for the server

Linux — edit the systemd unit:

$ sudo vim /etc/systemd/system/ollama.service

[Service]
Environment="OLLAMA_DEBUG=1"
Environment="OLLAMA_HOST=0.0.0.0:11434"

Setting OLLAMA_HOST=0.0.0.0 lets other hosts on the network reach Ollama on that port.

$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama

macOS:

$ launchctl setenv OLLAMA_HOST "0.0.0.0"
$ ollama serve

Windows: Search Edit the System Variables → Environment Variables → New, set name/value, OK/Apply.

Next Steps

Ollama is installed and serving models locally. From here:

Pair it with Open WebUI for a chat-style GUI
Set OLLAMA_HOST=0.0.0.0 to expose it to other machines on your network
Script ollama run/ollama pull against your own prompts to benchmark models on your hardware

For the full guide, visit the original article on Vultr Docs.

Deploying Akaunting – An Open-Source FreshBooks Alternative

Sanskriti Harmukh — Fri, 24 Jul 2026 14:08:02 +0000

Akaunting is an open-source, web-based accounting platform with invoicing, financial reporting, expense management, and payment tracking, a self-hosted alternative to QuickBooks, WaveApps, or FreshBooks with full control over your accounting data. This guide deploys Akaunting on a LEMP stack, using an external MySQL database server for reliability, and walks through Nginx configuration, TLS, and first-run setup.

Prerequisites: a server with at least 2GB RAM, an external MySQL database (managed or self-hosted), a domain A record, LEMP stack installed, and an Akaunting account API key from akaunting.com/start.

Set Up the Database

Akaunting supports MySQL, PostgreSQL, or SQLite. In production, use an external database server to offload load from the application server.

1. Connect to your MySQL host:

$ mysql -h your-db-host -P 3306 -u dbadmin -p

2. Create the database and user:

mysql> CREATE DATABASE akauntingdb;
mysql> USE akauntingdb;
mysql> CREATE USER 'akauntingadmin'@'localhost' IDENTIFIED BY 'secure-password';
mysql> GRANT ALL PRIVILEGES ON akauntingdb.* TO 'akauntingadmin'@'localhost';
mysql> FLUSH PRIVILEGES;
mysql> EXIT

Install Akaunting

1. Install required PHP extensions:

$ sudo apt install php php-fpm php-mysql php-bcmath php-ctype php-curl php-dom php-fileinfo php-intl php-gd php-json php-mbstring php-xml php-zip

2. Verify PHP and Nginx:

$ php -v
$ sudo systemctl status nginx

Note the PHP version reported, you'll need it for the PHP-FPM socket path below.

3. Create the web root and download the latest release:

$ cd /var/www/html/
$ sudo mkdir akaunting.example.com
$ cd akaunting.example.com
$ sudo wget -O akaunting.zip https://akaunting.com/download.php?version=latest
$ sudo unzip akaunting.zip
$ sudo rm akaunting.zip

If unzip is missing: sudo apt install zip unzip.

4. Fix ownership:

$ cd /var/www/html/
$ sudo chown -R www-data:www-data akaunting.example.com

Configure Nginx

1. Create the vhost:

$ cd /etc/nginx/sites-available
$ sudo touch akaunting.conf
$ sudo vim akaunting.conf

2. Add the config (replace akaunting.example.com and the PHP-FPM socket version):

server {
        listen 80;
        server_name akaunting.example.com;
        root /var/www/html/akaunting.example.com;

        add_header X-Frame-Options "SAMEORIGIN";
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Content-Type-Options "nosniff";

        index index.html index.htm index.php;
        error_page 404 /index.php;
        charset utf-8;

        location / {
            try_files $uri $uri/ /index.php?$query_string;
        }

        location ~ \.(env|log) {
            deny all;
        }

        location ~ ^/(^app$|bootstrap|config|database|overrides|resources|routes|storage|tests|artisan) {
            deny all;
        }

        location ~ ^/(modules|vendor)\/(.*)\.((?!ico|gif|jpg|jpeg|png|js\b|css|less|sass|font|woff|woff2|eot|ttf|svg|xls|xlsx).)*$ {
            deny all;
        }

        location ~ \.php$ {
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include fastcgi_params;
        }

        location ~ /\.(?!well-known).* {
            deny all;
        }
    }

3. Enable and test:

$ sudo ln -s /etc/nginx/sites-available/akaunting.conf /etc/nginx/sites-enabled/
$ sudo nginx -t
$ sudo systemctl restart nginx

Secure the Server

1. Firewall:

$ sudo ufw status
$ sudo ufw allow 22 && sudo ufw enable
$ sudo ufw allow 80
$ sudo ufw allow 443
$ sudo ufw reload

2. TLS via Let's Encrypt:

$ sudo apt install python3-certbot-nginx
$ sudo certbot --nginx -d akaunting.example.com -m akaunting@example.com --agree-tos

Verify renewal:

$ sudo certbot renew --dry-run

Access and Configure Akaunting

Visit https://akaunting.example.com:

Pick a language, click Next.
Enter your MySQL Hostname, Username, Password, and Database name, then Next to test the connection.
Enter Company Name and Company Email.
Set Admin Email and Admin Password, then log in.
Enter your Akaunting API key (from your account dashboard) or generate one.
Fill in tax number, financial year start date, company address, country, and logo.
Pick a default currency and continue.
Create a sample invoice: add a customer, invoice details and items, save.
Under Settings → Email Service, configure SMTP so invoices and notifications send by email.

Troubleshooting

Connection timed out — check sudo ufw status for port 443, sudo systemctl status nginx, and sudo cat /var/log/nginx/error.log, then sudo systemctl restart nginx.

Could not connect to the database — log in as the app's DB user (mysql -u akauntingadmin -p) and run SHOW DATABASES; to confirm access; re-grant privileges as admin if the database is missing from the list.

Unable to save admin user/company info — wipe and re-extract the release:

$ sudo rm -r /var/www/html/akaunting.example.com/*
$ sudo wget -O /var/www/html/akaunting.example.com/akaunting.zip https://akaunting.com/download.php?version=latest
$ sudo unzip /var/www/html/akaunting.example.com/akaunting.zip
$ sudo chown -R www-data:www-data /var/www/html/akaunting.example.com/

Then create a fresh database and re-run setup.

502 Bad Gateway — confirm php -v matches the fastcgi_pass socket path in your vhost (/var/run/php/phpX.Y-fpm.sock); update and reload Nginx if they've drifted.

Missing API key — grab it from your Akaunting account dashboard and paste it into the app to unlock full features.

Next Steps

Akaunting is live with an external database, TLS, and a sample invoice. From here:

Enable multiple company profiles with an upgraded API key
Integrate SMTP for automated invoice delivery
Explore Akaunting's module ecosystem for payroll, CRM, or POS extensions

For the full guide, visit the original article on Vultr Docs.

Deploying Mautic – An Open-Source Marketing Automation Platform

Sanskriti Harmukh — Fri, 24 Jul 2026 14:07:10 +0000

Mautic is an open-source marketing automation platform for email campaigns, contact tracking, lead nurturing, and analytics, a self-hosted alternative to HubSpot or Marketo with full control over your data. This guide installs Mautic on Ubuntu 24.04 with a LEMP stack (Nginx, MySQL, PHP), sets up cron jobs for background processing, and walks through campaigns, segments, forms, and landing pages.

Prerequisites: Ubuntu 24.04 instance, non-root sudo user, domain A record pointing at the instance (e.g. mautic.example.com).

Install the LEMP Stack

1. Install Nginx, MySQL, and PHP first (see a standard LEMP guide), then verify each:

$ nginx -v
$ mysql --version
$ php -v

2. Install PHP extensions Mautic needs:

$ sudo apt install php-fpm php-mysql php-imap php-curl php-json php-gd php-xml php-mbstring php-zip php-intl php-bcmath php-opcache php-cli unzip -y

3. Remove Apache if it was pulled in as a dependency (conflicts with Nginx):

$ sudo apt remove apache2 -y

4. Tune PHP-FPM. Edit /etc/php/8.3/fpm/php.ini (replace 8.3 with your version):

$ sudo nano /etc/php/8.3/fpm/php.ini

memory_limit = 512M
upload_max_filesize = 50M
post_max_size = 50M
date.timezone = UTC
cgi.fix_pathinfo=0

5. Restart PHP-FPM:

$ sudo systemctl restart php8.3-fpm

Create the Database

$ mysql -u root -p

mysql> CREATE DATABASE mauticdb;
mysql> CREATE USER 'mauticuser'@'localhost' IDENTIFIED BY 'securepassword';
mysql> GRANT ALL PRIVILEGES ON mauticdb.* TO 'mauticuser'@'localhost';
mysql> FLUSH PRIVILEGES;
mysql> EXIT;

Install Mautic

1. Download and extract the latest release:

$ wget https://github.com/mautic/mautic/archive/refs/tags/6.0.0.zip
$ unzip 6.0.0.zip
$ sudo mv mautic-6.0.0 /var/www/html/mautic

2. Fix ownership:

$ sudo chown -R www-data:www-data /var/www/html/mautic
$ sudo chown www-data:www-data /var/www

3. Install Composer and npm, then verify:

$ sudo apt install composer npm -y
$ composer --version
$ npm --version

4. Install dependencies and set permissions:

$ cd /var/www/html/mautic
$ sudo -u www-data composer install
$ sudo chmod -R 755 /var/www/html/mautic

Configure Nginx, TLS, and Cron

1. Create the vhost:

$ sudo nano /etc/nginx/conf.d/mautic.conf

server {
    listen 80;
    server_name mautic.example.com;
    root /var/www/html/mautic;
    index index.php;
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

    location / {
        try_files $uri /index.php$is_args$args;
    }

    location ~ .php$ {
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
         include fastcgi_params;
    }

    location ~ \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ {
        expires 1y;
        access_log off;
        add_header Cache-Control "public";
    }
}

2. Test and reload:

$ sudo nginx -t
$ sudo systemctl reload nginx

3. Open the firewall and issue a certificate:

$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp
$ sudo ufw reload
$ sudo snap install certbot --classic
$ sudo certbot --nginx --redirect -d mautic.example.com -m hello@example.com --agree-tos

Verify renewal works:

$ sudo certbot renew --dry-run

4. Add cron jobs for background processing — segments, campaigns, email queue, imports, bounce fetch:

$ sudo -u www-data crontab -e

* * * * * php8.3 /var/www/html/mautic/bin/console mautic:segments:update  > /dev/null
5-59/15 * * * * php8.3 /var/www/html/mautic/bin/console mautic:campaigns:update  > /dev/null
10-59/15 * * * * php8.3 /var/www/html/mautic/bin/console mautic:campaigns:trigger  > /dev/null
2-59/15 * * * * php8.3 /var/www/html/mautic/bin/console mautic:emails:send  > /dev/null
* * * * * php8.3 /var/www/html/mautic/bin/console mautic:import  > /dev/null
@hourly php8.3 /var/www/html/mautic/bin/console mautic:email:fetch

Run the Web Installer

Visit https://mautic.example.com. You'll land on Ready to install. Click through:

Database Setup — driver MySQL PDO, host localhost, the database/user/password created earlier.
Admin user — username, password, recovery email.
Log in with the admin credentials you just set.

Core Features

The dashboard is your hub for contacts, emails, campaigns, forms, and more.

Stages — track a contact's position in the funnel; assign via behavior, campaigns, or external events.
Companies — group contacts under a business entity for B2B segmentation/reporting.
Contacts — capture leads with tags, company links, owners, and stage assignment.
Segments — dynamic, auto-updating filtered groups used for campaign targeting.
Assets — host white papers, PDFs, or other downloadable content (local or remote storage).
Forms — Campaign Forms (used inside campaign workflows) or Standalone Forms (embedded anywhere), built with a drag-and-drop field/action editor.
Landing Pages — theme-based or visual-builder pages for opt-ins, webinars, gated content.
Campaigns — drag-and-drop drip workflows driven by sources (segment/form), actions (send email, adjust points), decisions (opens/visits), and conditions (field match).
Emails — Triggered (campaign/form/points-driven, repeatable) or Segment (one-time newsletter-style) types, built in the visual editor.
Points — assign/subtract points on contact actions (Point Actions) and fire automated responses once a threshold is hit (Point Triggers), for lead scoring.

Next Steps

Mautic is running on Ubuntu 24.04 with a full LEMP stack, TLS, and cron-driven background processing. From here:

Build a lead-scoring model with Points and route hot leads via a Point Trigger
Wire a Standalone Form + Landing Page combo for a lead-gen campaign
Segment contacts by engagement and connect a drip Campaign for nurture sequences

For the full guide with additional tips, visit the original article on Vultr Docs.

Deploying HAProxy on Ubuntu 22.04

Sanskriti Harmukh — Fri, 24 Jul 2026 14:05:45 +0000

HAProxy is an open-source proxy that load-balances TCP and HTTP traffic across backend servers, routing each request based on health checks and your chosen balancing algorithm. This guide deploys HAProxy on Ubuntu 22.04 in front of two Apache backend servers connected over a private network, configures round-robin balancing with health checks, and enables the live statistics dashboard. By the end, you'll have HAProxy distributing traffic evenly across two backends with real-time monitoring.

Topology: One HAProxy server (public domain haproxy.example.com, private IP 10.128.0.2) plus two backend servers (10.128.0.3, 10.128.0.4) on the same private network.

Install HAProxy

1. Update and install:

$ sudo apt update
$ sudo apt install haproxy -y

2. (Optional) Pull a newer version via PPA if your distro's default is stale:

$ sudo add-apt-repository ppa:vbernat/haproxy-2.8 -y

3. Enable and verify:

$ sudo systemctl enable haproxy
$ sudo systemctl status haproxy

Active: active (running)

Configure HAProxy

The config file /etc/haproxy/haproxy.cfg ships with global (runtime settings) and defaults (timeouts, mode) sections already populated.

1. Back it up:

$ sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.backup

2. Open it:

$ sudo nano /etc/haproxy/haproxy.cfg

3. Append a frontend and backend:

frontend website-frontend
    bind *:80,*:443
    option httpchk GET /healthcheck
    default_backend servers

backend servers
    balance roundrobin
    server server-1 10.128.0.3:80 weight 1 check
    server server-2 10.128.0.4:80 weight 1 check

bind — listen on HTTP (80) and HTTPS (443).
option httpchk — health-check path/method used against backends.
balance roundrobin — distributes requests evenly in turn. Other modes: leastconn, source.
server ... weight 1 check — registers a backend with a load weight and enables health checking; HAProxy stops forwarding to a server that fails checks.

4. Append a stats listener:

listen stats
    bind *:8404
    mode http
    stats enable
    stats uri /stats
    stats auth admin:your_password
    stats refresh 10s

This exposes a live dashboard with connection counts, session/request rates, response times, and errors.

5. Restart HAProxy:

$ sudo systemctl restart haproxy

6. Open the firewall:

$ sudo ufw allow 80/tcp
$ sudo ufw allow 8404/tcp
$ sudo ufw reload

7. Confirm both backends are reachable over the private network:

$ ping 10.128.0.3
$ ping 10.128.0.4

Configure the Backend Servers

Repeat on each backend:

1. Install Apache:

$ sudo apt update
$ sudo apt install apache2 -y
$ sudo systemctl enable apache2

2. Replace the default page so you can tell backends apart:

$ cd /var/www/html/
$ sudo mv index.html index.BAK
$ sudo nano index.html

Server 1:

<!DOCTYPE html>
<html>
  <head><title>Server 1</title></head>
  <body><h1>Hello!</h1><p>This content is served by Server 1.</p></body>
</html>

Server 2: same, with Server 2 swapped in.

3. Fix ownership and restart:

$ sudo chown -R www-data:www-data /var/www/html/index.html
$ sudo systemctl restart apache2

4. Identify the private network interface:

$ ip a

Look for the interface carrying the 10.128.0.x-style address (varies by provider/setup) — note its name for the next step.

5. Allow port 80 on that interface:

$ sudo ufw allow in on YOUR_PRIVATE_IFACE to any port 80
$ sudo ufw reload

Test the Load Balancer

1. Visit the HAProxy domain in a browser:

http://haproxy.example.com

Refresh a few times — responses alternate between "Server 1" and "Server 2" thanks to round-robin.

2. Open the stats dashboard:

http://haproxy.example.com:8404/stats

Log in with the stats auth credentials from the config. You'll see live frontend/backend metrics including connections, request rates, response times.

Next Steps

HAProxy is load-balancing traffic across two backends with health checks and live stats. From here you can:

Add more backend servers to the servers backend block to scale horizontally
Switch balance to leastconn for workloads with long-lived connections
Put TLS termination on HAProxy itself with the ssl crt bind option, or keep it behind a dedicated TLS proxy

For the full guide with additional tips, visit the original article on Vultr Docs.

Deploying Redpanda Kafka-Compatible Streaming Platform on Ubuntu 24.04

Sanskriti Harmukh — Tue, 07 Jul 2026 21:47:18 +0000

Redpanda is a Kafka-API-compatible streaming platform written in C++ with no JVM and no ZooKeeper. This guide installs Redpanda on Ubuntu 24.04, secures it with a Let's Encrypt certificate and SASL/SCRAM authentication, tunes the kernel for production, verifies with a producer/consumer test, and exposes Redpanda Console behind Nginx basic auth. By the end, you'll have a secured, production-tuned single-node Redpanda cluster with a web console.

Prerequisite: Ubuntu 24.04 server sized per Redpanda's CPU/memory requirements, non-root sudo user, and a domain A record (e.g. redpanda.example.com).

Install Redpanda

$ sudo apt update
$ curl -1sLf 'https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/cfg/setup/bash.deb.sh' | sudo -E bash

Warning: Only run vendor setup scripts you trust — piped curl | sudo bash runs with root privileges.

$ sudo apt install redpanda -y
$ rpk --version

Open the Firewall

Port	Service	Purpose
9092	Kafka API	Producer/consumer traffic
8082	Pandaproxy (HTTP)	REST access for non-Kafka clients
8081	Schema Registry	Avro/Protobuf schema versioning
9644	Admin API	Monitoring, config, health checks
33145	Internal RPC	Inter-node communication

$ sudo ufw allow 9092,8082,8081,9644,33145/tcp
$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp
$ sudo ufw reload

Issue a Let's Encrypt Certificate

Redpanda ships with plaintext networking by default, fine for a lab, not for anything else.

$ sudo apt install certbot -y
$ DOMAIN=redpanda.example.com
$ EMAIL=admin@example.com
$ sudo certbot certonly --standalone -d $DOMAIN --non-interactive --email $EMAIL

Certbot stores certs under /etc/letsencrypt/live, readable only by root. Redpanda runs as its own redpanda user, so copy the certs into a dedicated directory:

$ sudo mkdir /etc/redpanda/certs
$ sudo cp /etc/letsencrypt/live/$DOMAIN/fullchain.pem /etc/redpanda/certs/node.crt
$ sudo cp /etc/letsencrypt/live/$DOMAIN/privkey.pem /etc/redpanda/certs/node.key
$ sudo cp /etc/letsencrypt/live/$DOMAIN/chain.pem /etc/redpanda/certs/ca.crt
$ sudo chown -R redpanda:redpanda /etc/redpanda/certs/
$ sudo chmod 400 /etc/redpanda/certs/node.key
$ sudo chmod 444 /etc/redpanda/certs/node.crt /etc/redpanda/certs/ca.crt

Automate renewal — Let's Encrypt certs expire every 90 days, so wire a deploy hook that refreshes Redpanda's copies and restarts the service:

$ sudo nano /etc/letsencrypt/renewal-hooks/deploy/redpanda-renewal.sh

#!/bin/bash
DOMAIN="redpanda.example.com"

cp /etc/letsencrypt/live/$DOMAIN/fullchain.pem /etc/redpanda/certs/node.crt
cp /etc/letsencrypt/live/$DOMAIN/privkey.pem /etc/redpanda/certs/node.key
cp /etc/letsencrypt/live/$DOMAIN/chain.pem /etc/redpanda/certs/ca.crt

chown -R redpanda:redpanda /etc/redpanda/certs/
chmod 400 /etc/redpanda/certs/node.key
chmod 444 /etc/redpanda/certs/node.crt /etc/redpanda/certs/ca.crt

systemctl restart redpanda

$ sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/redpanda-renewal.sh
$ sudo certbot renew --dry-run

Tune for Production

$ sudo rpk redpanda mode production
$ sudo rpk redpanda tune all
$ sudo systemctl start redpanda-tuner

tune all optimizes I/O schedulers and CPU settings, takes ~30 seconds. The tuner service reapplies these on every reboot since kernel tuning doesn't persist otherwise.

Bootstrap Authentication

Set security policy before the first startup so it's enforced from the very first boot.

$ sudo nano /etc/redpanda/.bootstrap.yaml

enable_sasl: true
admin_api_require_auth: true
superusers:
  - admin

Note: This file is only read on first startup. Later changes go through the Admin API or rpk cluster config.

Set the superuser's password:

$ echo "RP_BOOTSTRAP_USER=admin:STRONG_PASSWORD:SCRAM-SHA-256" | sudo tee -a /etc/default/redpanda

Configure the Node

$ sudo cp /etc/redpanda/redpanda.yaml /etc/redpanda/redpanda-backup.yaml
$ sudo nano /etc/redpanda/redpanda.yaml

Replace the contents (swap redpanda.example.com for your domain):

redpanda:
  data_directory: /var/lib/redpanda/data
  seed_servers: []

  rpc_server:
    address: 0.0.0.0
    port: 33145
  advertised_rpc_api:
    address: redpanda.example.com
    port: 33145

  kafka_api:
    - name: tls_listener
      address: 0.0.0.0
      port: 9092
      authentication_method: sasl
  advertised_kafka_api:
    - name: tls_listener
      address: redpanda.example.com
      port: 9092
  kafka_api_tls:
    - name: tls_listener
      key_file: /etc/redpanda/certs/node.key
      cert_file: /etc/redpanda/certs/node.crt
      truststore_file: /etc/redpanda/certs/ca.crt
      enabled: true
      require_client_auth: false

  admin:
    - address: 0.0.0.0
      port: 9644
  admin_api_tls:
    - enabled: true
      key_file: /etc/redpanda/certs/node.key
      cert_file: /etc/redpanda/certs/node.crt
      truststore_file: /etc/redpanda/certs/ca.crt

rpk:
  tune_network: true
  tune_disk_scheduler: true
  tune_disk_nomerges: true
  tune_disk_write_cache: true
  tune_disk_irq: true
  tune_cpu: true
  tune_aio_events: true
  tune_clocksource: true
  tune_swappiness: true
  coredump_dir: /var/lib/redpanda/coredump
  tune_ballast_file: true

This enables SASL-over-TLS on the Kafka API (9092), TLS on the Admin API (9644), advertises both under your public domain, and applies the full rpk tuning profile.

$ sudo systemctl start redpanda
$ sudo systemctl status redpanda

Create an rpk Profile

Run rpk as your regular user (not sudo) so it picks up your profile.

$ nano ~/rpk-profile.yaml

kafka_api:
  sasl:
    user: admin
    password: STRONG_PASSWORD
    mechanism: SCRAM-SHA-256
  tls:
    enabled: true
    ca_file: /etc/redpanda/certs/ca.crt
  brokers:
    - redpanda.example.com:9092

admin_api:
  tls:
    enabled: true
    ca_file: /etc/redpanda/certs/ca.crt
  addresses:
    - redpanda.example.com:9644

$ rpk profile create production --from-profile ~/rpk-profile.yaml
$ rpk cluster health

CLUSTER HEALTH OVERVIEW
=======================
Healthy:                          true
Unhealthy reasons:                []
Controller ID:                    0
All nodes:                        [0]
Nodes down:                       []
Cluster UUID:                     65e28fbb-c1b4-42c3-b0b7-fd82608699f3

Test with a Producer and Consumer

$ rpk topic create test-topic

TOPIC       STATUS
test-topic  OK

$ echo "Hello Redpanda" | rpk topic produce test-topic

Produced to partition 0 at offset 0 with timestamp 1699618845123.

$ rpk topic consume test-topic --num 1

Deploy Redpanda Console

$ sudo apt install redpanda-console -y
$ sudo nano /etc/redpanda/redpanda-console-config.yaml

server:
  listenPort: 8080
  listenAddress: 127.0.0.1

kafka:
  brokers:
    - redpanda.example.com:9092
  tls:
    enabled: true
    caFilepath: /etc/redpanda/certs/ca.crt
  sasl:
    enabled: true
    username: admin
    password: STRONG_PASSWORD
    mechanism: SCRAM-SHA-256

redpanda:
  adminApi:
    enabled: true
    urls:
      - https://redpanda.example.com:9644
    tls:
      enabled: true
      caFilepath: /etc/redpanda/certs/ca.crt
    authentication:
      basic:
        username: admin
        password: STRONG_PASSWORD

$ sudo systemctl enable redpanda-console
$ sudo systemctl start redpanda-console

Front the Console with Nginx Basic Auth

Redpanda Console CE has no built-in login — put Nginx basic auth in front of it.

$ sudo apt install nginx -y
$ sudo apt install apache2-utils -y
$ sudo htpasswd -c /etc/nginx/.htpasswd admin

$ sudo nano /etc/nginx/sites-available/redpanda-console

server {
    listen 80;
    server_name redpanda.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name redpanda.example.com;

    ssl_certificate /etc/letsencrypt/live/redpanda.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/redpanda.example.com/privkey.pem;

    location / {
        auth_basic "Restricted Access";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

$ sudo ln -s /etc/nginx/sites-available/redpanda-console /etc/nginx/sites-enabled/
$ sudo nginx -t
$ sudo systemctl restart nginx

Open https://redpanda.example.com, enter the basic-auth credentials to reach the console dashboard.

Next Steps

Redpanda is running with TLS, SASL auth, production tuning, and a secured console. From here you can:

Add more brokers and set seed_servers for a multi-node cluster
Wire Kafka Connect or a schema registry client against port 8081
Point existing Kafka producers/consumers at Redpanda. The wire protocol is compatible, no client changes needed

For the full guide with additional tips, visit the original article on Vultr Docs.

Deploying SFTPGo as an Azure Storage SFTP Alternative on Linux

Sanskriti Harmukh — Tue, 07 Jul 2026 21:42:43 +0000

Azure Storage SFTP is Microsoft's managed file transfer service on top of Azure Blob Storage, convenient, but billed continuously per endpoint (roughly $0.30/hour, ~$220/month) and tied to Azure AD. SFTPGo is an open-source file transfer server offering SFTP, FTP/S, and WebDAV with pluggable storage backends (local disk, Azure Blob, S3-compatible, GCS) and no per-endpoint charge. This guide deploys SFTPGo with Docker Compose and Traefik, sets up user auth (password + SSH key + 2FA), connects S3-compatible object storage, and covers the migration path from Azure Storage SFTP. By the end, you'll have a self-hosted file transfer server with the same capabilities at zero endpoint cost.

Azure Storage SFTP → SFTPGo Mapping

Azure Storage SFTP	SFTPGo Equivalent	Notes
SFTP Endpoint	SFTPGo SFTP Server	Configurable port, default `2022`
Azure Blob Storage	Azure Blob backend	Native support; point at the same container, no migration needed
Azure AD Authentication	LDAP/OIDC plugin	External identity provider via plugin
Local Users	Web UI / REST API user management
Hierarchical Namespace	Virtual directories	No HNS requirement
Azure Monitor	Built-in logging + webhooks/syslog

Prerequisite: Linux server with Docker + Compose, a DNS A record for your domain, and (if migrating) an existing Azure Storage account with SFTP enabled plus the Azure CLI installed locally.

Deploy with Docker Compose

1. Create the project directories:

$ mkdir -p ~/sftpgo/{data,config}
$ cd ~/sftpgo

2. Create the environment file:

$ nano .env

DOMAIN=sftp.example.com
LETSENCRYPT_EMAIL=admin@example.com

3. Create the Compose manifest:

$ nano docker-compose.yml

services:
  traefik:
    image: traefik:v3.6
    container_name: traefik
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
      - "--certificatesresolvers.letsencrypt.acme.email=${LETSENCRYPT_EMAIL}"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "letsencrypt:/letsencrypt"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
    restart: unless-stopped

  sftpgo:
    image: drakkan/sftpgo:v2.7
    container_name: sftpgo
    restart: unless-stopped
    ports:
      - "2022:2022"
      - "2121:2121"
      - "10080:10080"
    environment:
      - SFTPGO_HTTPD__BINDINGS__0__PORT=8080
      - SFTPGO_HTTPD__BINDINGS__0__ADDRESS=0.0.0.0
      - SFTPGO_SFTPD__BINDINGS__0__PORT=2022
      - SFTPGO_FTPD__BINDINGS__0__PORT=2121
      - SFTPGO_WEBDAVD__BINDINGS__0__PORT=10080
      - SFTPGO_DATA_PROVIDER__DRIVER=sqlite
      - SFTPGO_DATA_PROVIDER__NAME=/var/lib/sftpgo/sftpgo.db
    volumes:
      - ./data:/srv/sftpgo
      - ./config:/var/lib/sftpgo
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.sftpgo.rule=Host(`${DOMAIN}`)"
      - "traefik.http.routers.sftpgo.entrypoints=websecure"
      - "traefik.http.routers.sftpgo.tls.certresolver=letsencrypt"
      - "traefik.http.services.sftpgo.loadbalancer.server.port=8080"
    healthcheck:
      test: ["CMD", "sftpgo", "ping", "-c", "/var/lib/sftpgo"]
      interval: 30s
      timeout: 10s
      retries: 3

volumes:
  letsencrypt:

Traefik terminates TLS on 80/443 for the admin UI; SFTP/FTP/S/WebDAV listen directly on 2022/2121/10080. Port 8080 (the admin UI's internal port) is never exposed to the host — Traefik proxies to it over the Docker network.

4. Start the stack:

$ docker compose up -d
$ docker compose ps
$ docker compose logs

Initial Admin Setup

Open https://sftp.example.com/web/admin.
Create the administrator: username, strong password, confirm, Create admin and Sign in.
Review Server Manager → Configurations — check the SFTP, ACME, and SMTP sections match your requirements.

Create a User and Configure Authentication

1. Password auth: Users → Add — username, password, Status: Active, File system: Local disk, Root directory: /srv/sftpgo/USERNAME. Save.

2. SSH key auth (passwordless, mirrors Azure's SSH key support):

$ ssh-keygen -t ed25519 -f ~/.ssh/sftpgo_key -C "sftp-user"
$ cat ~/.ssh/sftpgo_key.pub

Paste the public key into Users → Edit → Public keys, then test:

$ sftp -i ~/.ssh/sftpgo_key -P 2022 USERNAME@sftp.example.com

3. 2FA: Users → Edit → ACLs → Require 2FA for — select the protocols to gate. The user sets up their authenticator app on next WebClient login.

Connect S3-Compatible Object Storage

SFTPGo supports Azure Blob directly, but also any S3-compatible provider — useful if you're consolidating storage away from Azure.

Gather your endpoint URL, access key, secret key, and bucket name from the provider.
Users → Edit → File system → Storage: S3 (Compatible).
Fill in Bucket, Region, Access Key, Access Secret, Endpoint (full URL).
Enable Use path-style addressing.
Save, then verify:

$ echo "Hello SFTPGo" > testfile.txt
$ sftp -P 2022 USERNAME@sftp.example.com
sftp> put testfile.txt
sftp> ls
sftp> exit

S3 backend limitations: resume uploads disabled, no symlinks, non-atomic directory rename, chmod/chown silently ignored.

Test All Protocols

$ echo "Hello SFTPGo" > testfile.txt
$ sftp -P 2022 USERNAME@sftp.example.com
sftp> put testfile.txt
sftp> get testfile.txt /tmp/testfile-downloaded.txt
sftp> exit

$ sftp -i ~/.ssh/sftpgo_key -P 2022 USERNAME@sftp.example.com

$ sudo apt install lftp -y
$ lftp -u USERNAME -p 2121 ftp://sftp.example.com
lftp> ls
lftp> exit

Migrate from Azure Storage SFTP

Export Users

$ az storage account local-user list --account-name STORAGE_ACCOUNT --resource-group RESOURCE_GROUP
$ az storage account local-user show --account-name STORAGE_ACCOUNT --resource-group RESOURCE_GROUP --name USERNAME

Record username, SSH public keys, home directory (container + path), and permission scope for each user.

Recreate Users in SFTPGo

$ curl -u ADMIN_USERNAME:ADMIN_PASSWORD https://sftp.example.com/api/v2/token

Copy the access_token — it expires in 15 minutes.

$ curl -X POST "https://sftp.example.com/api/v2/users" \
    -H "Authorization: Bearer ACCESS_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "username": "USERNAME",
      "password": "PASSWORD",
      "status": 1,
      "public_keys": ["SSH_PUBLIC_KEY"],
      "home_dir": "/srv/sftpgo/data/USERNAME",
      "permissions": {"/": ["*"]}
    }'

"status": 1 is required — without it the account is created disabled.

Migrate Data

If SFTPGo will use Azure Blob as its own backend, just point users at the same container — no data transfer needed. For local-disk backends, pull the data down:

$ az storage blob download-batch --account-name STORAGE_ACCOUNT --source CONTAINER_NAME --destination ~/sftpgo/data/USERNAME/
$ sudo chown -R 1000:1000 ~/sftpgo/data/

Map Authentication Methods

Azure Method	SFTPGo Equivalent
SSH Public Keys	Public Keys (direct)
Local User Passwords	Password Authentication
Azure AD (Preview)	LDAP/OIDC plugin, or external auth hook

Update Clients

Document the new endpoint (sftp.example.com, port 2022, SSH key or password) and roll it out before decommissioning the Azure endpoint. Export SFTPGo's SSH host key (/var/lib/sftpgo/id_*) and share the fingerprint so clients don't hit host-key warnings.

Things to Watch

Hierarchical Namespace: Azure Storage SFTP requires HNS; SFTPGo simulates directories without it — check any app that depends on HNS-specific behavior.
Container-level permissions: map to SFTPGo's per-directory ACLs.
Lifecycle policies: SFTPGo doesn't manage Azure Blob lifecycle rules — keep configuring those in Azure if you stay on the Blob backend.
Azure Monitor: replace with SFTPGo's logging, syslog, or webhook integrations.

Next Steps

SFTPGo is running as a self-hosted Azure Storage SFTP replacement with zero per-endpoint charge. From here you can:

Enable the Azure Blob backend directly if you want to keep data in place
Set quotas, bandwidth limits, and IP ACLs per user under Edit → Disk quota / ACLs
Wire event hooks (webhooks/syslog) to replace Azure Monitor alerting

For the full guide with additional tips, visit the original article on Vultr Docs.

DEV Community: Sanskriti Harmukh

Deploying Kubernetes Dashboard and Managing Cluster Resources

Install the Dashboard

Configure Access

Access via Port Forwarding

Secure It with Ingress + TLS

Deploy an App from the Dashboard

Next Steps

Deploying Strapi on a Kubernetes Cluster

Build the Strapi Application

Containerize the Application

Build and Push the Docker Image

Prepare the Cluster

Install the Nginx Ingress Controller

Install cert-manager and a ClusterIssuer

Deploy Strapi

Scale the Deployment

Next Steps

Deploying MariaDB on Kubernetes

Create Persistent Volume and Claim

Deploy the MariaDB StatefulSet

Access MariaDB

Scale the Deployment

Next Steps

Deploying CockroachDB on Kubernetes

Install the CockroachDB Operator

Create a CockroachDB Cluster

Access the Cluster

Next Steps

Deploying Apache Cassandra on Kubernetes

Install cqlsh

Install cert-manager

Install the K8ssandra Operator

Deploy a Multi-Node Cassandra Cluster

Verify Persistent Storage

Expose the Cluster

Test the Cluster

Next Steps

Deploying Gateway API with TLS Encryption on Kubernetes

Install Envoy Gateway

Install cert-manager

Configure a ClusterIssuer

Deploy a Sample App

Initialize the Gateway

Configure Secure Routing

Next Steps

Deploying Large Language Models (LLMs) with Ollama

Install Ollama

Linux

macOS

Windows

Download Models

Run Models

Manage Models

Environment Variables

Next Steps

Deploying Akaunting – An Open-Source FreshBooks Alternative

Set Up the Database

Install Akaunting

Configure Nginx

Secure the Server

Access and Configure Akaunting

Troubleshooting

Next Steps

Deploying Mautic – An Open-Source Marketing Automation Platform

Install the LEMP Stack

Create the Database

Install Mautic

Configure Nginx, TLS, and Cron

Run the Web Installer

Core Features

Next Steps

Deploying HAProxy on Ubuntu 22.04

Install HAProxy

Configure HAProxy

Configure the Backend Servers

Test the Load Balancer

Next Steps

Deploying Redpanda Kafka-Compatible Streaming Platform on Ubuntu 24.04

Install Redpanda

Install `cqlsh`