How do I run a Monero miner on Kubernetes?

You can run a Monero miner on Kubernetes by packaging a miner such as XMRig in a container and deploying it with strict CPU and memory limits. Only do this on hardware you own or have explicit permission to use, and check your hosting provider’s mining policy first. Kubernetes manages the miner; it does not make mining faster or more profitable.

Choose the right setup

Use a native CPU miner, not a browser tab inside a container. Browser mining adds restrictions and overhead that are usually a poor fit for Kubernetes.

Monero uses RandomX, a mining algorithm designed to favor CPUs. For fast mode, budget for:

• A 2,080 MB dataset, plus a 256 MB cache and other memory overhead.
• About 2 MB of L3 cache per mining thread. L3 is fast memory shared by CPU cores.
• Sustained CPU load, electricity use, and heat.

Start with one miner on one approved worker node. A Deployment, which keeps a chosen number of application copies running, is a good starting point. Avoid a DaemonSet initially: it can spread miners across many nodes.

Build and deploy a limited miner

Build an image from a verified XMRig release or reviewed source. Pin the resulting image by its digest—a fingerprint that identifies its exact contents. Do not trust random “ready-made mining” images.

Label your approved node:

kubectl label node YOUR_NODE mining=approved

Save this as miner.yaml, replacing the image, pool address, and wallet placeholders:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: monero-miner
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: monero-miner
  template:
    metadata:
      labels:
        app: monero-miner
    spec:
      nodeSelector:
        mining: approved
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: xmrig
          image: YOUR_REGISTRY/xmrig@sha256:YOUR_DIGEST
          command: ["/usr/local/bin/xmrig"]
          args:
            - "--url=YOUR_POOL:TLS_PORT"
            - "--user=YOUR_PUBLIC_XMR_ADDRESS"
            - "--pass=k8s-worker"
            - "--tls"
            - "--threads=1"
            - "--randomx-mode=fast"
            - "--randomx-no-numa"
            - "--no-huge-pages"
          resources:
            requests:
              cpu: "1"
              memory: "3Gi"
            limits:
              cpu: "1"
              memory: "3Gi"
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]

Your image must provide XMRig at that path and support the non-root user. Use your pool’s documented TLS endpoint; TLS encrypts the connection.

Apply and inspect it:

kubectl apply -f miner.yaml
kubectl logs -f deployment/monero-miner
kubectl top pod

The last command requires Kubernetes Metrics Server.

Check safety and performance

Look for accepted shares in the logs: these are work submissions your pool accepts. Compare the pool’s longer-term reported speed with XMRig’s local hashrate, meaning calculations per second.

The example deliberately disables huge pages, a memory feature that can improve RandomX performance. Enabling them requires host preparation and Kubernetes huge-page resource configuration. Do not solve permission errors by making the container privileged.

Keep mining away from production workloads. CPU limits constrain CPU time, but miners still compete for shared cache and memory bandwidth. Do not expose XMRig’s management interface publicly.

Your miner needs only your public receiving address—not your wallet seed or private keys.

The bottom line

Start small, monitor accepted shares, and compare electricity or cloud charges against a live mining calculator. Cloud mining is often uneconomical. Stop the deployment whenever needed with kubectl scale deployment monero-miner --replicas=0; Kubernetes convenience does not guarantee a profit.