PmRails 2.0 and DkRails 2.0 — quick, disposable Rails environments with Podman or Docker

rubyonrails-talk
1

I’ve released PmRails 2.0, and also DkRails 2.0, a Docker-based counterpart with a similar workflow.

Both are intended to make it quick to get to the point where rails test or rails server works, without installing Ruby or Rails on the host.

The main use case

The main use case I have in mind is not necessarily replacing your everyday development environment.

It is more about cases where you want to quickly try Rails with an unfamiliar setup—for example:

  • another Ruby or Rails version
  • PostgreSQL instead of SQLite
  • a different configuration
  • reproducing an issue in a clean environment
  • briefly trying a gem or implementation idea

In those situations, setting up the environment is usually not the real goal. The goal is the experiment itself.

If Podman or Docker is already installed, I want PmRails/DkRails to make it easy to spin up the environment, run the experiment, and throw it away when you are done.

What changed in v2

PmRails started as a relatively small set of wrappers around Podman.

Version 2 expands it into a more complete workflow for Rails development and testing, including:

  • single-container development
  • Compose-based Rails + database + Selenium environments
  • initialization of existing Rails projects
  • presets for PostgreSQL, MySQL, MariaDB, and SQLite
  • custom Dockerfile and Compose support

DkRails brings essentially the same workflow to Docker.

For example:

pmrails-cmpexe bin/rails test

or:

dkrails-cmpexe bin/rails test

The full release notes are here:

Relation to Dev Containers and custom Compose setups

PmRails/DkRails are not intended to replace Dev Containers or a well-maintained project-specific Compose setup.

If those already fit your workflow, there may be little reason to replace them.

The intended niche is a lighter-weight entry point: keep your editor and other development tools on the host, while running Rails and related services in containers. Starting with PmRails/DkRails and later moving to a custom Compose setup or Dev Container is also an expected path.

A side benefit for AI coding agents

One side benefit I’ve found useful is that the same boundary also works well with AI coding agents.

For example, with Codex I can allow selected Rails commands:

prefix_rule(
    pattern = [
        "pmrails-cmpexe",
        "bin/rails",
        ["test", "test:system", "routes", "zeitwerk:check"],
    ],
    decision = "allow",
)

This lets the agent run common Rails operations automatically while application execution stays on the container side.

I do not consider this a security sandbox—mounted files, databases, network access, and so on still matter—but I find the separation useful.

I’d be especially interested in feedback from people who regularly switch between Rails versions, databases, or temporary test environments, as well as people using containers together with coding agents.

1 Like