DEV Community: Matsuoka Seiji

“It Works in Docker” — But Will It Work in Kubernetes?

Matsuoka Seiji — Mon, 22 Jun 2026 09:54:37 +0000

Introducing Raind Promote Strategy: a workflow for validating applications from containers to Pods

Recently, I published an article introducing Raind, a container runtime I have been building.

GitHub: https://github.com/shizuku198411/Raind

Raind is an experimental runtime that can run both Docker-like containers and Kubernetes-like Pods within a single runtime environment. In this article, I want to introduce one of the new features I recently implemented:

Promote Strategy.

Promote Strategy is a workflow for validating whether an application can actually start and run correctly across multiple deployment styles:

as a single container
as a multi-container application
as Kubernetes-style resources and Pods

In other words, it helps answer a question many developers have faced:

“It works as a container, but will it still work when I move it toward Kubernetes?”

What is Promote Strategy?

Promote Strategy is a feature that lets you define and run an application validation workflow across multiple stages.

A typical workflow looks like this:

Start the application as containers.
Check whether each container is running.
Validate application behavior, such as HTTP responses.
Promote the running container state into a Compose-style configuration draft.
Start the application again as a multi-container application.
Promote it into Kubernetes-style resource manifests.
Apply those resources.
Validate that the application still behaves correctly as Pods.

The key point is that Raind does not simply convert static configuration files.

It validates the application at each stage and generates reviewable configuration drafts based on the actual runtime state.

Why not just start with Kubernetes?

If the goal is Kubernetes deployment, it may sound unnecessary to validate the application as a container first.

But Kubernetes deployment assumes that the application image itself can already run correctly as a container.

Kubernetes also introduces many additional concepts:

readiness probes
jobs
ingress
services
CNI behavior
resource manifests
scheduling behavior

For developers who are not deeply familiar with Kubernetes, starting directly with a Kubernetes deployment can make debugging harder.

If something fails, it may not be immediately clear whether the issue is the application image, environment variables, container startup behavior, inter-container communication, Kubernetes manifests, service discovery, networking, or some other deployment-specific setting.

Promote Strategy helps split this process into smaller stages.

First, verify that the application works as containers.

Then verify that multiple containers can communicate.

Then verify that the same application can run as Kubernetes-style resources.

This makes it easier to isolate where a problem appears.

Why not just use Docker and Kubernetes directly?

This is a fair question.

In many cases, using Docker and Kubernetes directly is the most reliable approach.

However, there are situations where developers may not want to install or run both Docker and Kubernetes on the same development machine. For example:

the development environment is fixed, such as inside a Dev Container
Kubernetes is only available on another host
the developer does not want to install heavy runtime infrastructure locally
staging or sandbox environments exist, but are not easy to use casually
testing requires pushing images to a registry before they can be used elsewhere

Even when CI/CD pipelines exist, they are not always ideal for quick local validation.

Raind is not trying to replace Docker or Kubernetes.

Instead, it focuses on a narrower goal:

validating whether an application can start and communicate correctly before it is deployed to production-like infrastructure.

Why not use kind or minikube?

For Kubernetes deployment testing, tools like kind and minikube are great options.

But they primarily provide Kubernetes clusters. They are not designed to focus on the step-by-step transition from a single container to a multi-container application and then to Pods.

In practice, developers may still move between:

Docker for container-level testing
Docker Compose for multi-container behavior
kind or minikube for Kubernetes behavior

That means using multiple tools and multiple runtime models.

Raind’s goal is to provide a single runtime where the application startup path can be validated consistently from container to Pod.

What Raind is trying to solve

Raind is not intended to be fully compatible with Docker or Kubernetes.

It is also not meant to be a toy runtime that simply imitates both systems.

The goal is more focused:

before deploying to production, verify that the application can at least start correctly as a Container, as a Compose-style multi-container application, and as a Pod.

There is an important difference between:

“the deployment is production-ready”
“the application can start and behave correctly”

Raind focuses on the second part.

Promote Strategy exists to validate that application startup behavior across stages.

Generating reviewable configuration drafts

Promote Strategy does more than run tests.

It also generates reviewable configuration files while promoting the application across stages.

For example:

after the container stage passes, Raind generates a Compose-style compose.yaml
after the Compose-style stage passes, Raind generates Kubernetes-style manifests

These generated files are not intended to be production-ready.

Instead, they provide a validated starting point.

Runtime-based generation

The generated files are based on runtime state.

Raind checks things such as:

whether the containers are actually running
what environment variables are applied inside the containers
what command or entrypoint is being used
what ports and mounts are active
what communication occurs between containers
what network policies are required

This makes the generated configuration more useful than a simple static conversion.

For example, a generated Compose draft may include the actual command, environment variables, ports, mounts, and dependencies observed from the running containers.

Secret-like values are masked in the reviewable output, so the generated files can be inspected more safely.

Example: WordPress + MySQL

A Promote Strategy definition describes the initial containers, communication policy, and validation checks.

Here is a simplified example using WordPress and MySQL:

apiVersion: raind.io/v1alpha1
kind: PromoteStrategy

metadata:
  name: wordpress-stack

source:
  mode: create
  containers:
    - name: mysql
      image: mysql:8
      env:
        MYSQL_ROOT_PASSWORD: root-password
        MYSQL_DATABASE: wordpress-db
        MYSQL_USER: wordpress-user
        MYSQL_PASSWORD: wordpress-password
      volume:
        - /mnt/mysql:/var/lib/mysql

    - name: wordpress
      image: wordpress:latest
      env:
        WORDPRESS_DB_HOST: mysql
        WORDPRESS_DB_NAME: wordpress-db
        WORDPRESS_DB_USER: wordpress-user
        WORDPRESS_DB_PASSWORD: wordpress-password
      ports:
        - "9850:80"

  policies:
    - type: ew
      source: wordpress
      destination: mysql
      protocol: tcp
      destPort: 3306
      comment: allow wordpress database access

stages:
  container:
    checks:
      runtime:
        - name: mysql-running
          type: containerStatus
          target: mysql
          expect:
            state: running
          timeout: 60s
          interval: 2s

        - name: wordpress-running
          type: containerStatus
          target: wordpress
          expect:
            state: running
          timeout: 60s
          interval: 2s

  bottle:
    checks:
      runtime:
        - name: bottle-running
          type: bottleStatus
          target: wordpress-stack
          timeout: 60s
          interval: 2s

      application:
        - name: wordpress-http
          type: http
          target: http://127.0.0.1:9850/wp-admin/login.php
          expect:
            status: 200
          timeout: 90s
          interval: 2s

  resources:
    checks:
      application:
        - name: wordpress-http
          type: http
          target: http://127.0.0.1:9850/wp-admin/login.php
          expect:
            status: 200
          timeout: 90s
          interval: 2s

The strategy defines the seed containers, the allowed communication between containers, runtime checks, application checks, and the stages that should be validated.

Then the workflow can be executed with:

raind promote strategy

Example output

When the strategy succeeds, Raind generates files under raind_promote.

Typical outputs include:

raind_promote/
  bottle/
    bottle.yaml
  compose/
    compose.yaml
  resources/
    00-namespace.yaml
    01-configmap.yaml
    02-secret.example.yaml
    03-pvcs.yaml
    04-deployments.yaml
    05-services.yaml
    07-networkpolicies.yaml
    REVIEW.md
    all.yaml

The generated manifests may still need tuning.

For example:

secret values should be replaced or managed properly
production readiness probes may need to be added
exposure strategy may need to change from NodePort to Ingress
resource limits may need to be defined
operational jobs may need to be added

But the important part is that the generated files are based on a configuration that has already passed application startup validation.

They are a foundation, not the final production deployment.

Roadmap

Promote Strategy is still in an early stage.

Future improvements may include:

more validation check types
richer generated configuration
broader Kubernetes-style resource support
better policy generation
deeper integration with AI agents or MCP-based workflows

One idea I am exploring is allowing an AI agent to review and generate deployment drafts based on real application validation results, without giving the agent direct access to Docker or Kubernetes itself.

Closing thoughts

Raind is still experimental, and it is not intended to replace Docker or Kubernetes.

But I believe there is value in a runtime that focuses specifically on validating application startup before production deployment.

Promote Strategy is a step toward that goal.

It helps bridge the gap between:

“the container starts”
“the multi-container application works”
“the application can run as Kubernetes-style resources”

If you are interested, the project is available on GitHub:

https://github.com/shizuku198411/Raind

Stars, feedback, and issues are very welcome.

Introducing Security Profiles for Container Permission Management

Matsuoka Seiji — Tue, 16 Jun 2026 10:38:19 +0000

Introduction

In this article, I want to introduce Security Profiles, a feature I added to Raind, a container runtime I have been developing.

In a previous article, I introduced Raind as a runtime that aims to handle Docker-like standalone container execution and Kubernetes-style resources such as Pod, Deployment, Service, and Ingress as part of a single runtime stack.

GitHub repository: https://github.com/shizuku198411/Raind

This time, I would like to talk about one of the main features in the recent release: Security Profile.

A Security Profile is a reusable profile that manages security-related container settings such as Linux capabilities, seccomp, and AppArmor.

In Docker, capability management is usually done through command-line options such as --cap-add and --cap-drop.

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx

This is flexible, but when the same security configuration needs to be maintained across multiple containers or environments, it can gradually become harder to manage.

For example:

It becomes difficult to see which container has which capabilities
Development and production environments may end up with different settings
Unexpected capabilities may remain enabled without being noticed
Capabilities, seccomp, and AppArmor settings are not easy to view as one security policy

To solve this, Raind introduces Security Profiles as a way to visualize, reuse, and manage these settings as a single unit.

What is a Security Profile?

A Security Profile is a named configuration that groups container security settings together.

Currently, a profile mainly manages the following settings:

Security Profile
  ├── Linux capabilities
  ├── seccomp deny filter
  └── AppArmor profile name

When creating or running a container, you can specify a profile with --security-profile.

raind container run --security-profile deploy nginx:latest

Instead of directly listing fine-grained capabilities for every container, you can express the intent like this:

Run this container with the deploy profile

Raind aims to handle containers, Pods, traffic policies, and network observability inside the runtime itself.

Security Profile follows the same direction: instead of treating security settings as scattered command-line options, Raind treats them as something closer to a runtime-managed resource.

Built-in Profiles

Raind provides several built-in profiles.

Here is the current list of built-in profiles:

Profile	Use case	Summary
`default`	Standard execution	Raind's default capability set + seccomp + AppArmor
`dev`	Development	Currently similar to `default`, intended as a development baseline
`deploy`	Application deployment	Drops `CAP_NET_RAW` and `CAP_MKNOD` from `default`
`restricted`	Stronger restriction	Uses an empty base capability set
`privileged`	Workloads that require broad privileges	Enables a wide set of known capabilities and disables seccomp / AppArmor
`unconfined`	Keep default capabilities but remove confinement	Keeps default capabilities while disabling seccomp / AppArmor

If no profile is specified, default is used.

The profiles I personally consider especially important are deploy and restricted.

The deploy profile is intended for typical application workloads. It removes CAP_NET_RAW and CAP_MKNOD from the default capability set.

CAP_NET_RAW is related to raw sockets, which are often unnecessary for typical web applications.

CAP_MKNOD is related to creating device files, which is also not usually required for general application containers.

So the intended usage is to start with deploy as a baseline for application workloads, and only add extra capabilities when they are actually needed.

Listing Profiles

Security Profiles can be listed from the CLI.

raind security profile ls

list is also available as an alias.

raind security profile list

The output looks like this:

NAME          TYPE      CAPABILITIES  SECCOMP   APPARMOR
default       built-in  14 caps       enabled   raind-default
dev           built-in  14 caps       enabled   raind-default
deploy        built-in  12 caps       enabled   raind-default
restricted    built-in  0 caps        enabled   raind-default
privileged    built-in  41 caps       disabled  -
unconfined    built-in  14 caps       disabled  -

This makes it possible to check the number of capabilities, whether seccomp is enabled, and which AppArmor profile is used.

Instead of having to inspect each container's launch command to understand its security settings, Raind exposes them as profiles.

Inspecting a Profile

You can inspect the details of a profile with show.

raind security profile show deploy

This shows the actual capabilities, seccomp configuration, and AppArmor profile used by the profile.

name: deploy
type: built-in
capabilities:
    base:
        - CAP_CHOWN
        - CAP_DAC_OVERRIDE
        - CAP_FSETID
        - CAP_FOWNER
        - CAP_SETGID
        - CAP_SETUID
        - CAP_SETFCAP
        - CAP_SETPCAP
        - CAP_NET_BIND_SERVICE
        - CAP_SYS_CHROOT
        - CAP_KILL
        - CAP_AUDIT_WRITE
seccomp:
    defaultAction: SCMP_ACT_ALLOW
    defaultErrnoRet: 1
    architectures:
        - SCMP_ARCH_AARCH64
    syscalls:
        - names:
            - bpf
            - perf_event_open
            - kexec_load
            - open_by_handle_at
            - ptrace
            - process_vm_readv
            - process_vm_writev
            - userfaultfd
            - reboot
            - swapon
            - swapoff
            - open_by_handle_at
            - name_to_handle_at
            - init_module
            - finit_module
            - delete_module
            - kcmp
            - mount
            - unshare
            - setns
          action: SCMP_ACT_ERRNO
          errnoRet: 1
apparmorProfile: raind-default

This profile-based approach is important from a security perspective.

If you only keep stacking --cap-add and --cap-drop options, the final permission set becomes harder to understand. As the number of added or dropped capabilities grows, it becomes easier to accidentally end up with a capability set that was not intended.

By managing these settings as a profile, it becomes easier to explain:

This workload runs with this permission baseline

That makes the configuration more readable and easier to audit.

Applying a Profile to a Container

A Security Profile can be specified when creating or running a container.

raind container run --security-profile deploy nginx:latest

It can also be used with container create.

raind container create \
  --name web \
  --security-profile restricted \
  nginx:latest

raind container start web

When a Security Profile is specified, the profile is used as the base capability set.

You can also apply container-specific differences with --cap-add and --cap-drop.

raind container run \
  --security-profile deploy \
  --cap-add CAP_NET_BIND_SERVICE \
  --cap-drop CAP_NET_RAW \
  nginx:latest

In this case, Raind first resolves the deploy profile, then applies the container-specific capability changes on top of it.

In other words:

Profile = baseline policy
cap-add / cap-drop = per-container difference

This separation makes it easier to keep shared security policies in profiles, while still allowing small per-container adjustments when necessary.

Creating a Custom Profile

If you frequently need to combine --security-profile, --cap-add, and --cap-drop, it usually means that the built-in profiles are not enough for that use case.

For that reason, Raind also supports custom profiles.

A custom profile can extend an existing built-in profile or another custom profile, then adjust the capability set with add-cap and drop-cap.

For example, here is a custom development profile that extends dev, adds CAP_SYS_PTRACE, and drops CAP_NET_RAW.

apiVersion: raind.io/v1
kind: SecurityProfile
metadata:
  name: custom-dev
spec:
  extends: dev
  add-cap:
    - CAP_SYS_PTRACE
  drop-cap:
    - CAP_NET_RAW

You can register it with:

raind security profile register -f custom-dev.yaml

After registration, it can be used in the same way as built-in profiles.

raind container run --security-profile custom-dev alpine:latest sh

Currently, custom profiles mainly handle capability differences.

seccomp and AppArmor settings are inherited from the parent profile. In the future, I would like to make seccomp and AppArmor more configurable from custom profiles as well.

Why Manage This as a Profile?

Container security settings may look like small launch options when viewed individually.

However, in practice, they are strongly related to the nature of the workload and the security policy of the environment.

For example, the profiles can represent different baselines:

dev
  Baseline that prioritizes development convenience

deploy
  Baseline for typical application workloads

restricted
  Strongly restricted baseline

privileged
  Explicitly privileged workload baseline

If these are expressed only through repeated --cap-add and --cap-drop options, the command becomes longer and the meaning of the configuration becomes harder to understand.

A profile gives a name to the security intent, not just to the list of capabilities.

raind container run --security-profile deploy nginx:latest

From this command, you can immediately tell that the container is intended to run with the deploy baseline.

Then, by running raind security profile show deploy, you can inspect the actual capability set, seccomp settings, and AppArmor profile.

The main purpose of Security Profile is to bring the security intent and the actual runtime configuration closer together.

How This Differs from Docker

Docker already supports security-related mechanisms such as Linux capabilities, seccomp profiles, and AppArmor profiles.

For example, capabilities can be adjusted with --cap-add and --cap-drop, and seccomp or AppArmor can be configured with security options.

However, these are usually specified as individual container launch options.

Raind's Security Profile is different in that it groups capabilities, seccomp, and AppArmor into a named runtime-level profile.

The difference is not that Docker lacks security features. Docker already has many of them.

The difference is that Raind tries to manage these settings as a reusable profile that represents the security baseline of a workload.

Docker:
  container run options
    ├── --cap-add
    ├── --cap-drop
    ├── seccomp option
    └── AppArmor option

Raind:
  security profile
    ├── capabilities
    ├── seccomp
    └── AppArmor

This makes it easier to ask questions such as:

Which security baseline is this workload using?
What capabilities does this profile allow?
Is seccomp enabled for this profile?
Which AppArmor profile is applied?

The Raind Direction

As mentioned in the previous article, Raind already handles traffic policies and netflow logs inside the runtime.

Security Profile is another step in the same direction.

Raind
  ├── Container / Pod execution
  ├── Service / Ingress
  ├── Traffic Policy
  ├── Netflow Observability
  └── Security Profile

Raind is not only trying to run containers.

The goal is to let the runtime manage:

Which communication is allowed
Which communication actually happened
Which permissions a container has
Which seccomp / AppArmor settings are applied

This is still experimental, but Raind is gradually becoming more like a workload runtime rather than just a docker run alternative.

Conclusion

In this article, I introduced Security Profile in Raind.

With Security Profile, container security settings such as capabilities, seccomp, and AppArmor can be managed as named profiles instead of being scattered across command-line options.

This makes it easier to:

List and inspect security settings
Define workload-specific baselines
Reduce configuration differences between environments
Notice unexpected capability grants
Understand the execution intent from the container command

In the future, I would like to improve custom profiles so that they can manage seccomp and AppArmor in a more flexible way. I also want to integrate Security Profiles more deeply with Kubernetes-style resources such as Pod and Deployment.

Raind is still under development, but I will continue building it toward a runtime that can manage workload execution, networking, observability, and security together.

What if Docker-like local containers and Kubernetes-like workload resources shared the same runtime path?

Matsuoka Seiji — Tue, 16 Jun 2026 09:41:33 +0000

Github Repository: https://github.com/shizuku198411/Raind

Docker-like containers, Kubernetes-inspired resources, and runtime-level observability in one local runtime

Container tooling is usually split across several layers.

Docker-style tools are great when you want to build an image, run a single container, publish a port, mount a directory, or quickly inspect logs.

Kubernetes-style systems are great when you want to describe workloads as Pods, Services, Deployments, and network-oriented resources.

But in local development and runtime experimentation, these layers often feel disconnected. A single container, a multi-container application, and a Kubernetes-style workload are usually treated as separate worlds, even though they eventually depend on the same Linux primitives: namespaces, cgroups, mounts, networking, process execution, and runtime state.

Raind is an experimental project that tries to connect these layers.

Raind is a local container runtime and lightweight workload orchestrator for Linux. It provides Docker-like container commands, Kubernetes-inspired workload resources, runtime-managed networking, traffic visibility, security policy, and rootless container support through one runtime stack.

The project is still early and under active development, but the goal is clear:

Make container-level and workload-level execution testable, controllable, and observable through one consistent runtime path.

Why I Built Raind

Modern container workflows are powerful, but they can also become fragmented.

When using Docker-like tools, the experience is simple and direct:

docker run nginx
docker exec ...
docker logs ...

But once the workload grows beyond a single container, the user often moves to another layer: Compose, Kubernetes, service meshes, network policy engines, observability tools, and runtime-specific debugging tools.

Each tool solves a real problem, but the overall development experience can become harder to reason about:

Where is the workload state managed?
Which component owns networking?
Which layer applies policy?
Where can I see container-to-container traffic?
Can I test Kubernetes-like resources locally without leaving the runtime model?
Can single containers and Pod-style workloads share the same execution foundation?

Raind was started as an experiment to answer these questions from the runtime side.

Instead of treating container execution, workload resources, network policy, and traffic logs as unrelated systems, Raind tries to make them part of the same runtime architecture.

The Runtime Stack

Raind is split into three main layers:

raind CLI
  -> condenser
    -> droplet

`raind` CLI

raind is the user-facing command-line tool.

It exposes workflows for containers, images, networks, resources, Bottles, policies, and logs:

raind image ...
raind container ...
raind network ...
raind resource ...
raind bottle ...
raind security policy ...
raind logs ...

Condenser

Condenser is the high-level runtime service.

It owns image handling, container state, networking state, Kubernetes-style resource stores, controllers, policy state, DNS handling, netflow logs, Service and Ingress behavior, and the generation of low-level runtime specs.

Condenser does not directly become a container process. Instead, it manages workload intent and delegates low-level container execution to Droplet.

Droplet

Droplet is the low-level OCI-style runtime layer.

It is responsible for Linux container mechanics such as namespace setup, mount setup, pivot_root, cgroups, capabilities, seccomp, AppArmor on-exec handling, runtime state, attach, and exec.

This split allows Raind to keep high-level workload management and low-level container execution separate, while still making them part of one runtime path.

Docker-Like Container Workflows

At the container level, Raind supports a familiar Docker-like workflow.

For example:

raind container run --name web -p 8080:80 nginx:latest
raind container exec web /bin/sh
raind container logs web
raind container stop web
raind container rm web

A Raind container can use image references, published ports, bind mounts, environment variables, commands, logs, lifecycle operations, and exec.

Under the hood, the container is executed through Droplet. That means container lifecycle operations eventually pass through the same low-level runtime path used by higher-level workload resources.

The container unit is useful for:

testing a single image
debugging runtime behavior
checking lifecycle behavior
running local services
validating namespace, mount, networking, and exec behavior

Bottles: Local Multi-Container Application Units

Raind also includes a concept called a Bottle.

A Bottle is a local multi-container application unit. It is intended for workloads that are larger than one container but do not necessarily need a full Kubernetes-style manifest.

A Bottle can describe multiple services, ports, mounts, dependencies, environment variables, and policy behavior in one YAML file.

Typical commands look like this:

raind bottle create -f bottle.yaml
raind bottle start wordpress
raind bottle show wordpress
raind bottle stop wordpress

The idea is similar in spirit to local multi-service application definitions, but Raind keeps the Bottle inside its runtime model. That means Bottle workloads can share the same container lifecycle, networking, policy, and observability mechanisms as other Raind workloads.

This is especially useful when testing communication between containers.

For example, instead of only asking “did the containers start?”, Raind can also help answer:

Which container is talking to which other container?
Is that communication expected?
Should this east-west traffic be allowed?
Can I observe the traffic from the runtime?

Kubernetes-Inspired Resources

Raind also supports Kubernetes-style resource workflows.

The goal is not to replace Kubernetes. Instead, Raind provides a local runtime path for experimenting with Kubernetes-inspired workload concepts.

Raind currently supports resources such as:

Namespace
Pod
ReplicaSet
Deployment
Service
Ingress

Example workflow:

raind resource apply -f app.yaml
raind resource pod ls
raind resource replicaset ls
raind resource deployment ls
raind resource service ls
raind resource rm -f app.yaml

A Pod groups one or more containers into a shared runtime unit. ReplicaSet and Deployment add reconciliation behavior. Service provides stable traffic handling for matching Pods. Ingress provides external routing through Raind’s local runtime layer.

The important part is that these resources are not managed by a completely separate execution path. They eventually map back to the same low-level container runtime foundation.

This makes Raind useful for testing transitions between:

a single local container
a multi-container local application
a Pod-like workload
a Deployment-like reconciled workload
a Service-routed workload

Runtime-Level Policy and Netflow

One of the most important goals of Raind is to make workload communication visible and controllable from the runtime.

Raind includes runtime-managed policy and netflow logging.

Policy types include:

east-west container-to-container policy
namespace egress observation
namespace egress enforcement

Example policy command:

raind security policy add --type ew \
  --source frontend \
  --destination backend \
  --protocol tcp \
  --dport 8080 \
  --comment 'allow frontend to backend'

raind security policy commit

Raind also records network flow logs:

raind logs netflow --line 50
raind logs netflow --json
raind logs netflow -t web

The runtime can enrich traffic logs with metadata such as container ID, container name, IP address, interface, and identity information when available.

This is one of the areas where Raind’s workload-centric model becomes useful.

In many local environments, a workload may start correctly, but traffic visibility is still difficult. You might know that a frontend cannot reach a backend, but you may not immediately know whether the traffic was sent, where it went, whether it matched a policy, or how it maps back to runtime entities.

Raind tries to make those questions part of the runtime experience.

Rootless Containers

Raind also supports rootless execution for standalone containers.

Rootless support is currently focused on containers created through raind container run and raind container create. Pod-managed rootless containers are not supported yet.

Raind currently provides two rootless mapping modes.

`shifted-root`

This is the default rootless mode.

In this mode, container UID/GID ranges are shifted into a subordinate host ID range.

Conceptually:

container 0..65535 -> host 100000..165535

This isolates container root from the login user, but files written to bind mounts by container root may appear as subordinate host IDs.

`login-root`

The login-root mode is designed for a more Docker-rootless-like local development experience.

In this mode, container root maps to the invoking login user:

container 0        -> host login UID/GID
container 1..65535 -> host subordinate UID/GID range

This is useful when a development container writes into a bind-mounted project directory and the host user should be able to edit or remove the files without manual chown.

Example:

mkdir -p /tmp/raind-login-root

raind container run --name login-root-demo \
  --rootless-mode login-root \
  -v /tmp/raind-login-root:/data \
  alpine:latest /bin/sh -c 'id; echo hello > /data/hello.txt; sleep 60'

ls -lan /tmp/raind-login-root

Raind also separates rootless image layer caches by mapping policy, so shifted-root and login-root do not overwrite each other.

Rootless support is still evolving, but it is already an important part of the project direction.

Container Exec and Namespace Handling

raind container exec is also implemented as part of the runtime model.

Exec must enter the target container’s namespaces, adopt the target root filesystem, use the correct working directory, and resolve commands against the container environment rather than the host environment.

This sounds simple, but it is one of the areas where runtime details matter.

For example, a bare command such as:

raind container exec web nginx -v

should resolve nginx inside the container root filesystem, not on the host. It also has to work consistently for rootful and rootless containers.

Raind’s exec path uses namespace entry and container rootfs handling so that exec behavior matches the container’s runtime context.

This is one of the reasons Raind is interesting as a runtime experiment: features that look like simple CLI commands often force the runtime to make precise decisions about namespaces, rootfs, UID/GID mappings, environment variables, and process execution.

Current Status

Raind is experimental.

It is not intended to be a production container runtime today.

The current focus is:

container runtime stability
rootless execution
image handling
Dockerfile build support
Kubernetes-style resource compatibility
local workload networking
policy and netflow visibility
runtime security profiles
developer documentation and project maturity

The project already includes documentation for architecture, containers, rootless modes, networking, resources, manifests, runtime layout, testing, and security profiles.

But many areas are still evolving. Dockerfile parsing, image manifest handling, Kubernetes manifest compatibility, rootless networking, and production-grade hardening are all active areas of development.

Why This Project Matters

Raind is not trying to be “another Docker” or “a replacement for Kubernetes.”

It is a runtime experiment around a specific idea:

What if container execution, local workload orchestration, network policy, and runtime observability were designed as one connected system?

That idea matters because local container workflows often sit between two worlds.

On one side, Docker-like tools are easy to use but mostly container-centric.

On the other side, Kubernetes-like systems are powerful but often too large when the goal is local runtime experimentation.

Raind explores the space between them.

It provides:

Docker-like container ergonomics
Kubernetes-inspired workload resources
Bottle-based local multi-container application units
runtime-managed network policy
netflow-based communication visibility
rootless container execution modes
a low-level OCI-style runtime layer implemented in Go

For developers interested in containers, Linux namespaces, cgroups, networking, policy, or local Kubernetes-style testing, Raind is a project worth exploring.

Getting Started

The repository is available on GitHub:

https://github.com/shizuku198411/Raind

A typical local flow looks like this:

raind image pull nginx:latest
raind network create devnet
raind container run --name web -p 8080:80 nginx:latest
raind container logs web
raind container exec web nginx -v

For Kubernetes-style resources:

raind resource apply -f app.yaml
raind resource pod ls
raind resource service ls

For runtime traffic visibility:

raind logs netflow --line 50

Raind is still young, but the project is moving quickly. Feedback, issues, ideas, and contributions are welcome.

If you are interested in container runtimes, Linux workload isolation, local Kubernetes-style workflows, or runtime-level traffic visibility, I would be happy if you tried Raind or followed the project.