Rig.dev it's an open source application platform to simplify developers experience with Kubernetes
Rig.dev offers an open-source application platform for Kubernetes as a free self-hosted solution or as a paid managed platform. The source code is available in their Github repositories and it's licensed under Apache 2.0 license.
The purpose is to help developers to work in their own environments with elevated application abstractions, while still leveraging Kubernetes's reliability, portability, and scalability.
One of the key features is a developer-friendly deployment engine, which simplifies the process of rolling out, managing, debugging and scaling applications. Also, it has a foundational APIs for user management, authentication, storage, and database integrations.
All of the above can be managed through a Dashboard, CLI, also has several CI/CD pipelines which integrate Rig.dev with GitHub Actions almost natively.
The logic is structured under "Capsules", described as:
A Capsule contains a bundle of resources which will be deployed as a unit. Those resources are
- A Docker image
- Environment variables
- Networking configuration (load balancer/ingress)
- Networking middleware to handle e.g. authentication
- Number of replicas
If you are familiar with Kubernetes, Capsules can be thought of as containing everything (deployment, service, ingress, etc.) needed to run and manage your application.
Read the docs, or just try it our using a local KinD cluster using their script:
#!/usr/bin/env bash
set -e
parent_path=$( cd "$(dirname "${BASH_SOURCE[0]}")" ; pwd -P )
KIND="${KIND:=kind}"
KUBECT="${KUBECTL:=kubectl --context kind-rig}"
HELM="${HELM:=helm --kube-context kind-rig}"
# Create kind cluster
${KIND} get clusters | grep "^rig$" || \
cat <<EOF | ${KIND} create cluster --name rig --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraPortMappings:
- containerPort: 30000
hostPort: 30000
listenAddress: "127.0.0.1"
protocol: TCP
EOF
# Ensure rig-system namespace exists
${KUBECTL} get namespace rig-system || \
${KUBECTL} create namespace rig-system
# Install docker registry in rig-system namespace
${KUBECTL} apply -n rig-system \
-f "${parent_path}/../../cmd/rig/cmd/dev/kind/registry.yaml"
# Ensure required repositories are available
${HELM} repo list | grep '^jetstack\s*https://charts.jetstack.io\s*$' || \
${HELM} repo add jetstack https://charts.jetstack.io
${HELM} repo list | grep '^metrics-server\s*https://kubernetes-sigs.github.io/metrics-server\s*$' || \
${HELM} repo add metrics-server https://kubernetes-sigs.github.io/metrics-server
${HELM} repo update
# Install cert-manager
${HELM} upgrade --install cert-manager jetstack/cert-manager \
--namespace cert-manager \
--create-namespace \
--version v1.13.0 \
--set installCRDs=true
# Install metrics-server
${HELM} upgrade --install metrics-server metrics-server/metrics-server \
--namespace kube-system \
--set args={--kubelet-insecure-tls}

Related content
How the Linux kernel copyfail vulnerability impacts kubernetes: What you need to know and what you can do
copy fail in kubernetes: when your pod escapes to the host with four bytes if you thought containers were a security boundary, cve-2026-31431 ("copy fail") has some unfortunate news for you. discovered by xint, this linux kernel vulnerability lets an unprivileged local user overwrite four controlled bytes in
Read the full post →
High severity Github Actions exploit: hackerbot-claw uses your ci/cd as a "pwn-as-a-service" platform
overview It turns out that automating your workflows also makes it incredibly easy for attackers to automate your demise. An autonomous attack campaign, tracked as "hackerbot-claw," is currently prowling public repositories. Its mission? Finding insecure GitHub Actions workflows and turning them into gateways for arbitrary code execution and