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:

1. Start the application as containers.
2. Check whether each container is running.
3. Validate application behavior, such as HTTP responses.
4. Promote the running container state into a Compose-style configuration draft.
5. Start the application again as a multi-container application.
6. Promote it into Kubernetes-style resource manifests.
7. Apply those resources.
8. 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.

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.

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:

1. after the container stage passes, Raind generates a Compose-style compose.yaml
2. 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.