Ask an AI to translate an Ansible role into Python and you get back a pile of subprocess and paramiko calls that reinvents configuration management — badly, and differently every time. The model is not the bottleneck. The bottleneck is that, until now, there was no Python library shaped like Ansible for the model to translate into. Reemote is that library. Once it is the target, which AI you use barely matters.

Paste a role, get spaghetti

Try it. Take an ordinary Ansible role — install a package, drop a config file, enable a service, open a firewall port — and ask a capable model to "rewrite this in Python."

You will get something that runs. It will import subprocess. It will shell out to apt-get install -y, check the return code, then systemctl enable, then maybe wrap the lot in a try/except. There will be no idempotence, or a hand-rolled version of it that greps dpkg -l. There will be no concurrency. The config file gets written with open(..., "w") on your laptop and pushed over with scp in a way that only works on the machine you tested it on.

Ask again tomorrow, or ask a different model, and you get a different pile of spaghetti. Neither is wrong the way a compiler is wrong; both are just ad hoc. Now spend more tokens — a longer prompt, a bigger context window, a reasoning model. The output gets longer and better commented. It does not get more consistent, and it does not converge on an architecture. That is the tell, and it is the whole subject of this article.

AI is a pattern matcher, and it needs a pattern

The "it's just autocomplete" dismissal of large language models is right for the wrong reasons. A model generates by matching patterns it has seen. Translation tasks go well when there is a target pattern to match against — a destination idiom that appears often enough in the training data that the model can lean on it instead of inventing one.

Compile C to assembly and the model has millions of examples of what good assembly looks like. Convert a JSON blob to a Python dataclass and the shape is obvious. But "translate an Ansible role to Python" has no canonical target. There is no widely-repeated idiom for configuration management in Python, because — as the next section establishes — nobody shipped the library that would have created one. So the model falls back to the nearest patterns it does have: subprocess, os.system, paramiko, Fabric-style SSH one-liners. Every generation re-derives a different arrangement of those primitives, because there is nothing to converge toward.

No amount of token spend fixes a missing pattern. You cannot prompt a model into an idiom that does not exist in the world yet.

There is no transpiler — and no framework to transpile into

It is worth being precise about the landscape, because "just use AI" sits on top of a real gap.

There is no official, automated transpiler that turns a YAML playbook into native Python. That is not for lack of trying; it is structural. Ansible playbooks are declarative orchestrations leaning on a state engine, an SSH/WinRM abstraction, dynamic variable handling, and an idempotence model. Python is procedural. The two do not line up statement-for-statement, so there is nothing to "compile."

What does exist falls into three buckets, and none of them is a target you would want an AI to translate into:

• Programmatic control of Ansible itself — ansible-runner, or Ansible's internal Python API (ansible.playbook.Play, DataLoader). These let a Python program launch playbooks and consume their events. They do not get you off Ansible; they wrap it. The YAML, the state engine, and the CLI-shaped result all remain.
• General Python automation frameworks — Fabric, or Pulumi's Python SDK. Fabric is SSH command execution: it hands you run("apt-get install ..."), which is exactly the low-level primitive the model was already reaching for, with no facts, no operations, no idempotence. Pulumi is a different paradigm again — cloud resource provisioning, not host configuration management.
• Raw building blocks — paramiko for SSH, requests for APIs, subprocess for everything else. This is the layer the model invents on top of when you give it nothing better.

Notice what all three lack: a configuration-management library with the same conceptual shape as Ansible — modules, facts, operations, idempotence — that you can import and call from Python. That library is the missing pattern. Until it exists, "transpile Ansible to Python" has no destination, and the AI has nothing to aim at.

The library matters more than the model

Here is the whole argument, stated plainly: for Ansible-to-Python migration, the choice of Python library dominates the choice of AI.

Give a model nothing and it invents an architecture every time. Give it a rich, consistent, well-documented library whose vocabulary lines up one-to-one with Ansible's, and the task collapses from "design a configuration-management system" to "map each task to the operation that already does this." That second task is exactly what models are good at, and it is bounded enough that a human can review the output.

The best current choice for that library is Reemote — not because it is magic, but because it is the thing that was missing: configuration management as a Python library, with the same conceptual model as Ansible, so there is finally an idiom for the model to converge on.

What Reemote is

Reemote is a Python package (pip install reemote) that does configuration management as a library rather than a CLI. There is no reemote binary. You write a deploy — a plain Python generator — and await it:

plans, report, hosts = await run(inventory, deploy)

Four words cover the model:

• Inventory — a list of dicts naming your targets and how to reach them (over SSH, or through a local docker connector).
• Fact — a read of remote state: the hostname, the installed packages, a file's contents, a service's status. Facts are typed, sorted, JSON-printable data structures, never scraped strings.
• Operation — a request to converge the server toward a described state. An operation reads facts, decides whether anything must actually change, and emits commands only when it must. That is idempotence, built into every operation rather than bolted on.
• Action — an immediate, non-deploy escape hatch (Shell, Script, WaitForConnection) for one-off commands.

A deploy yields operation requests in order:

def deploy(host):
    yield op(apt.packages, name="Install nginx", packages=("nginx",), sudo=True)
    yield op(files.install, name="Write landing page",
             content=PAGE, dest="/var/www/html/index.html", mode="0644", sudo=True)
    yield op(systemd.service, name="Run nginx",
             service="nginx", running=True, enabled=True, sudo=True)

That is the same three-step shape as the role at the top of this article — package, file, service — expressed as ordinary Python you can import, loop over, and unit-test.

The runner executes every deploy twice: once to plan against live facts, once to apply. Both passes must yield the identical request sequence or it raises a DeterminismError. dry=True stops after the plan and gives you a real preview against live state — Ansible's --check, but as a return value you can assert on instead of a wall of coloured diff output.

Why Reemote is the right transpilation target

The properties that make Reemote a good library are the same ones that make it a good destination for an AI migration. Here they are, each tied to what it removes from the translation problem.

Async end to end, on asyncssh

The transport is asyncssh, and the entire execution path — connecting, gathering facts, sending commands, closing — is coroutines. You await a deploy and hosts progress in parallel; network waits overlap across hosts while each host's commands stay in order. Your deploy script remains a plain synchronous generator, so you never write async inside an operation.

For a migration this matters because the model does not have to invent concurrency. Ansible gave you parallelism through forks; a naive Python translation loses it and loops over hosts one at a time. In Reemote the parallelism is a property of the runtime, not of the generated code — the AI produces the same simple generator either way, and the framework does the hard part.

A library returning structured results, not a CLI

Ansible is a CLI: the result of a run is terminal output, and if your program needs to know what changed you regex-scrape stdout and hope. run(...) instead returns (plans, report, hosts):

• plans — {host_label: [PlannedOperation, ...]}, the proposed work per host.
• report — an ApplyReport with one LogEntry per applied operation, each carrying changed, reason, and the exact commands that were sent. None when dry=True.
• hosts — the materialised host objects.

This is a target a model can hit reliably, because "read report.entries[i].changed" is an ordinary data-access pattern it has seen a million times — versus "parse Ansible's callback output," which it has not, and which changes between versions. Handlers become plain Python: read the first run's report, freeze the hosts that changed, and feed that set into a second deploy that restarts the service. No notify keyword, no handler-ordering rules to memorise.

Comprehensive modules — a one-to-one vocabulary with Ansible

This is the single biggest reason Reemote translates well. A model can only map apt_repository onto something if that something exists. Reemote ships twenty modules, and each one implements the whole surface of its domain as operations and facts — not just the common verbs.

Take apt. Ansible spreads package management across apt, apt_key, apt_repository, apt_mark, and a dozen parameters. Reemote's apt module covers the same ground with matching operations: packages (install/upgrade/remove by name, version-pinnable), repo and sources_file (legacy .list and modern deb822 sources), ppa, key (GPG keyrings), deb (a standalone .deb), mark (hold/unhold), update, upgrade, dist_upgrade, and auto_remove. Every operation reads a matching fact — what is installed, what is held, which sources are configured, which keys are trusted, what an upgrade would move, what an autoremove would clean — so nothing is faked with a shell one-liner and the read side is as complete as the write side.

That completeness is what makes translation near-mechanical:

The twenty modules span package managers (apt, dnf, apk, snap, flatpak), files and version control (files, git), services (systemd, openrc), firewalls (firewalld, iptables, ufw), system configuration (server, sysctl, selinux, hardware), keys (gpg), databases (mysql, postgresql), and containers (lxd). When the destination vocabulary is this complete, the model spends its effort choosing the right operation instead of reimplementing a missing one.

Pure functional deploys

Every request argument is hashable, a deploy is a pure function of its host, and the runner executes it twice — plan then apply — under a determinism guard that raises if the two passes disagree. There is no hidden mutable state, no reliance on the order a for loop happened to run in, no "did this already change?" flag threaded through globals.

For AI-generated code this is a safety net. Model output is plausible but unreviewed; a pure, deterministic deploy is testable. You can call the generator, inspect the requests it yields, and assert on them with pytest — no server required. And the determinism guard catches the classic model mistakes (a datetime.now(), a random, a lambda built inline) at plan time rather than in production. The framework enforces the discipline the generated code might otherwise lack.

No awareness of the controller file system

Ansible couples a playbook to the controller's disk. copy: src=app.conf, template: src=config.j2, and script: src=deploy.sh all resolve a path relative to the role's conventional directories (files/, templates/) through a search-path rule. The task's meaning depends on where files happen to live on the machine running Ansible — an implicit, invisible dependency the model has to guess at and reproduce.

Reemote has no such coupling. A deploy never takes a controller path:

• files.install takes content as a plain string — the text is right there in the code.
• files.put and files.get take an IO-like stream you opened yourself; a path string is deliberately not accepted.
• files.copy and files.move are remote-to-remote — src is a path on the target, not on the controller.

The result is that a Reemote deploy is self-contained and pure: given the same host and the same arguments it produces the same requests, with nothing implicit read off the controller's layout. For a transpiler that removes an entire class of guesswork — the AI never has to replicate Ansible's role-directory search magic or invent a file layout. It renders the content (from a string, a Pydantic model, or a Jinja2 template pre-rendered control-side) and hands it to an operation.

What this means for your migration

Point the model at Reemote's module reference as context, feed it the role, and ask it to map each task to an operation. Because the vocabulary lines up, the output is bounded and reviewable: a generator of op(...) requests, not an architecture. You read it the way you would read any pull request — does this operation match that task, are the privilege flags right, is the content correct.

The constructs that do not map one-to-one — handlers, host_vars, Jinja2 templates, lineinfile edits, get_url downloads — each have a documented Reemote shape, and the migration guide works through them construct by construct with before/after pairs. That guide is the human companion to this argument: once you accept that the library is the right target, it shows you the exact mappings. See the Ansible role migration guide.

The model still matters, of course — a stronger model makes fewer mistakes. But it is a second-order effect. The first-order effect is whether there is a framework to translate into. Now there is.

What Reemote is not

Honest boundaries, because overselling helps nobody:

• Not a deployment CLI. There is no reemote command. You write the script.
• Not an inventory format. Inventory is a Python list of dicts — load it from JSON, YAML, a database, or write it inline.
• Not a role ecosystem. Twenty modules ship in the box, but there is no Ansible Galaxy equivalent to pull third-party roles from.
• Not an OS translation layer. Python does not make nginx installable by the same name on Alpine and Debian. You still pick the right module for the target — the AI still has to know apk from apt.
• Not an automatic transpiler. Reemote is the target, not the translator. The AI does the mapping and you review it. The library's job is to make that mapping bounded, idiomatic, and testable — which is precisely the part that was impossible before.

Try it

• Documentation and full guide: https://reemote.org/
• Ansible role migration guide: https://reemote.org/migrating/
• Source: https://github.com/kimjarvis/reemote
• PyPI: pip install reemote
• License: EPL-2.0

If you have tried to get an AI to translate an Ansible role and come away with unreviewable spaghetti, the fix was never a bigger prompt. It was a library worth translating into. Give Reemote a minute.

We will stand up nginx, serve a static landing page, run a small Flask app behind it on a Unix socket, and finish with HTTPS from Let's Encrypt. Everything is ordinary Python: for loops, if statements, imports, types, and pytest.

This is a written walkthrough you can follow along at home. Every output block labelled verified was produced by running the code shown against a local ubuntu:24.04 container through reemote's docker connector; the production-only steps (systemd, Certbot) are marked as such because a plain container cannot run them, and the article says so rather than implying otherwise.

What is reemote?

Reemote is a configuration-management library. You describe the state a machine should be in — packages installed, files present, services running — and reemote works out the shell commands that get it there, then runs them across your fleet concurrently.

A file full of those descriptions is a deploy. Here is the whole idea in a few lines:

from reemote import apt, files, op, server

MOTD = "Managed by reemote\n"

def deploy(host):
    for user in ("admin", "alice", "bob"):
        yield op(server.user, user=user)

    yield op(files.install, dest="/etc/motd", content=MOTD, sudo=True)

    if host.extra.get("install_postgres"):
        yield op(apt.packages, packages=("postgresql",), sudo=True)

A deploy is a generator: it yields one op(...) request per action. op records the call — it does not run it. The runner drives the generator twice (once to plan, once to apply), which is why every argument must be hashable: packages=("postgresql",) is a tuple, not a list. host.extra is arbitrary per-host data from the inventory, so the if is just Python.

Why use reemote?

Reemote is declarative — you describe the target state, and reemote makes it so — and idempotent — nothing happens if the machine is already in that state. Those are the properties that make a deploy safe to re-run.

Unlike a YAML-driven tool, a deploy is Python code, so you get everything Python gives you:

• Your editor knows your code. apt.packages, files.install, and systemd.service are functions: go-to-definition, autocomplete, rename, and a type check that catches a typo before it reaches a production box.
• No second templating language. There is no {{ hostvars[...] }} stringly-typed escape hatch. A value is a Python expression, evaluated by the interpreter you already trust, and config text is rendered control-side with plain Python before you hand it to files.install.
• Composition is import. Roles are generator functions you call, loop over, and yield from — not a directory layout loaded by convention.
• The result is data, not stdout. run(...) returns structured objects; you read report.log[i].changed instead of regex-scraping a terminal.
• Testing is pytest. A deploy is a pure generator; you can assert on the requests it yields without a server in sight.
• await is the concurrency model. Hosts progress in parallel because the transport is asyncssh, not because a CLI forked workers you have to configure.

In fairness, reemote ships fewer built-in modules than a decade-old tool with a galaxy of roles. That is partly offset by how little code a custom operation takes — an async generator that reads a fact and yields a command, as the Certbot step later in this article shows.

When to use reemote?

Reemote's use cases follow from what it does: configure machines over SSH (or inside a container). It is a good fit for boring, cloud-agnostic architectures, from a fleet of servers with different roles all the way down to one-computer programming, where it still makes a setup reproducible and prevents drift.

It is easy enough to learn that it works well for self-hosting and home servers, and even when you do not want full configuration management, the Shell action gives you a convenient way to run ad-hoc commands across a fleet.

Simplicity has edges. There is no built-in pull mode, a fully automated pipeline is your own code around await run(...), and two people deploying at once need coordination. Reemote does not provision cloud resources — that is Terraform's job; reemote configures the machines once they exist. Staying "commands over SSH" is a deliberate scope, not a gap.

Install reemote

Reemote runs on your controller — the machine running the Python — and needs Python 3.13 or newer. You never install it on the target servers; they only need SSH (or, for this walkthrough, a container runtime).

Install from a git checkout. That is the recommended route here because the clone also gives you the runnable examples/ tree this article walks through:

git clone https://github.com/kimjarvis/reemote.git
cd reemote
uv sync
source .venv/bin/activate

uv sync creates .venv, installs reemote in editable mode and resolves its dependencies — asyncssh, distro, pydantic — so the SSH transport needs no separate step. uv is what we use; venv and pip work just as well. If you only want the library and not the examples, uv pip install reemote from PyPI is enough.

Every stage below has a complete, runnable script under examples/tutorials/website/, so you can read the article and run the code side by side:

website_0.py is the smallest complete program — the "basic part" the rest build on. Run it, and the others, with uv run from the checkout root:

uv run python examples/tutorials/website/website_0.py

The examples target a local container named beta, so start it once — the walkthrough uses podman, and docker works identically:

podman run -d --name beta ubuntu:24.04 tail -f /dev/null

Pointing the docker connector at a container name rather than an image leaves it running between runs, so its state persists like a VM — which is what makes idempotence visible. website_4.py is the exception: it targets two production SSH hosts and Certbot, so it builds and dry-runs offline but is meant to be pointed at your own servers.

The demo

At the end we will have two websites — a landing page and a Python web app — deployed in two stages.

First a single local target, beta, running both behind one nginx:

.------- beta --------.- app.beta --------.
|                    nginx                 |
|    static website   :   Python web app   |
'------------------------------------------'

...then two separate production servers, one per site:

.-- web1 (prod) ---.  .-- web2 (prod) ----.
|      nginx       |  |      nginx        |
|  static website  |  |  Python web app   |
'------------------'  '-------------------'

Here is a sneak peek at the finished top-level deploy. It composes a shared nginx base with two conditional sub-deploys, then handles reloads as a second pass:

def deploy(host):
    yield from nginx_base(host)                       # apt + disable default site

    if host.extra.get("home_domain"):                 # static landing page
        yield from sub_deploy(home_site, name_prefix="home")(host)

    if host.extra.get("app_domain"):                  # Flask app behind gunicorn
        yield from sub_deploy(app_site, name_prefix="app")(host)

The ifs read host.extra — static inventory data — so both phases of the run resolve them identically. That distinction (static data versus live facts) is the single most important rule in reemote, and the next two sections are about it.

Operations and facts

Two concepts do all the work.

Operations change the machine

An operation ensures some state: a file exists, a package is installed, a service is running. Most are declarative and idempotent. Here is a deploy with one operation that says "I want /tmp/hello.txt to exist":

# create_file.py
import asyncio
from reemote import files, format_log, format_plan, op, run

INVENTORY = [{
    "host": "beta",
    "connection": {"connector": "docker", "identifier": "beta", "docker_cmd": "podman"},
}]

def deploy(host):
    yield op(files.file, name="create hello.txt", path="/tmp/hello.txt", present=True)

async def main():
    plans, report, _ = await run(INVENTORY, deploy)
    print("== plan ==")
    print(format_plan(plans))
    if report is not None:
        print("== log ==")
        print(format_log(report))

asyncio.run(main())

beta here is a local container, so the walkthrough needs no SSH key and no VM. Start it once:

podman run -d --name beta ubuntu:24.04 tail -f /dev/null

Pointing the docker connector at a container name (rather than an image) leaves it running between runs, so state persists exactly like a VM. Run the script:

python create_file.py

Verified output — the plan says what will change, the log says what did and shows the command:

== plan ==
beta: create hello.txt         [changed: /tmp/hello.txt missing, will create]
== log ==
beta: create hello.txt         [changed: /tmp/hello.txt missing, will create]
    $ touch /tmp/hello.txt

Because files.file is idempotent, running the identical script again does nothing:

== plan ==
beta: create hello.txt         [no change: file /tmp/hello.txt already exists]
== log ==
beta: create hello.txt         [no change: file /tmp/hello.txt already exists]

There is no "press enter to execute" prompt — reemote is a library, not an interactive CLI. To look before you leap, pass dry=True: it runs the prepare phase only (facts are gathered for real, nothing mutates) and returns report=None. Preview with dry=True, then call run again without it to apply.

Facts read the machine

A fact gathers data about a target. Read one directly across hosts with gather_fact:

from reemote import Host, gather_fact, server

hosts = [Host.from_inventory(entry) for entry in INVENTORY]
names = await gather_fact(hosts, server.LinuxName)

Verified output:

gather_fact LinuxName -> {'beta': 'Ubuntu'}

The natural next step — pick a package name from the distribution — is where reemote differs most from a tool that lets you branch on a fact mid-deploy. You cannot. A deploy runs twice (prepare, then apply); if its body branched on a live fact, the two passes could diverge, so the runner raises a DeterminismError rather than silently applying a plan it did not show you. Static inventory data (host.name, host.group, host.tags, host.extra) is identical in both phases and safe to branch on; facts are not.

So fact-driven choice moves out of the deploy, into a gather → snapshot → factory shape:

from reemote import apt, gather_fact, op, run, server

# 1. Gather the fact up front, across every host, and freeze it.
names = await gather_fact(hosts, server.LinuxName)

# 2. Build a per-host dispatch table from the snapshot (keyed by host name).
PACKAGE = {"Ubuntu": "apache2", "Debian": "apache2"}

def build_install(name):
    package = PACKAGE.get(name, "httpd")
    def install(host):
        yield op(apt.packages, name="install apache", packages=(package,), sudo=True)
    return install

# 3. Run each host against a deploy chosen from its frozen value — never live.
for entry in INVENTORY:
    await run([entry], build_install(names[entry["host"]]))

The branch happens in ordinary Python before the deploy exists, so each deploy body is branch-free and deterministic. It is a little more code than an inline if, and in exchange the plan reemote shows you is a plan it will actually honour.

Where are the commands?

An operation is an async generator that takes an OpContext, reads facts to decide whether anything must change, and yields command descriptors only when it does. This is a simplified files.file:

from reemote import OpContext, StringCommand

async def file(ctx: OpContext, path: str, present: bool = True):
    exists = await ctx.facts.get(FileExists, path)

    if not exists and present:
        ctx.changed = True
        ctx.reason = f"{path} missing, will create"
        yield StringCommand(f"touch {path}")

    elif exists and not present:
        ctx.changed = True
        ctx.reason = f"{path} present, will remove"
        yield StringCommand(f"rm -f {path}")

The shape is the same for every operation: read state with a fact, diff it against the desired state, set ctx.changed/ctx.reason, and yield the commands that close the gap. Yield nothing and the operation reports "no change".

Here is a deploy that says "I want /tmp/hello.txt to not exist":

def deploy(host):
    yield op(files.file, name="delete hello.txt", path="/tmp/hello.txt", present=False)

format_log renders the command descriptors that were actually sent, which is where the shell text finally appears. Verified output (against the container that still has the file from earlier):

== plan ==
beta: delete hello.txt         [changed: /tmp/hello.txt present, will remove]
== log ==
beta: delete hello.txt         [changed: /tmp/hello.txt present, will remove]
    $ rm -f /tmp/hello.txt

The plan comes from the prepare phase: reemote runs each operation to see what it would yield, gathering facts (read-only commands) but sending nothing that mutates. The log comes from the apply phase: the same operations run again, and this time their commands are sent. Apply re-creates the fact cache before every step, so a later operation sees the effect of an earlier one — install a package in step 1 and step 2's package fact reads the newly-installed set.

Inventory + nginx setup

So far the target has been a local container, but we want beta to behave like production. The inventory is just a Python list of dicts — no separate file format to learn. Each entry names a host, its connection, and any extra data:

BETA = [{
    "host": "beta",
    "connection": {"connector": "docker", "identifier": "beta", "docker_cmd": "podman"},
}]

# Production is the same shape over the default ssh connector — the
# "connector" key can be omitted, since ssh is the default:
PROD = [{
    "host": "web1",
    "connection": {"address": "web1.example.com", "username": "deploy",
                   "key_path": "~/.ssh/id_ed25519"},
    "home_domain": "www.example.com", "stage": "prod", "nginx_https": True,
}]

Because the inventory is Python, a group does not have to be a literal — build it from a database query or your cloud's SDK ([i.hostname for i in ...]). The keys a Host does not recognise (home_domain, stage, nginx_https) are preserved verbatim in host.extra, which is how per-host data reaches the deploy.

To run an arbitrary command across the fleet — the ad-hoc "what version is this?" move — use the Shell action. Actions run immediately, outside the deploy model, and hand you the result as data:

from reemote import Host, Shell, gather_action

hosts = [Host.from_inventory(e) for e in BETA]
results = await gather_action(hosts, Shell, command='. /etc/os-release && echo "$PRETTY_NAME"')

Verified output:

Shell beta: exit=0 stdout='Ubuntu 24.04.5 LTS'

An action's exit status is data, not an exception — even 127 (command not found) comes back in exit_status so the caller decides what it means. Actions cannot run inside a deploy; gather_action raises the moment it is called from a generator.

Point it at a real server

The beta container needs no keys and no network, but the same deploys run against a real machine unchanged — only the inventory entry differs. To add a server you can SSH into, give its entry a connection with an address, a username and a key_path instead of the docker connector:

REAL = [{
    "host": "web1",                                  # any name you like
    "connection": {
        "address": "web1.example.com",               # or an IP
        "username": "deploy",                        # the login user
        "key_path": "~/.ssh/id_ed25519",             # its private key
    },
    # Any other keys land in host.extra and drive the conditional deploys:
    "home_domain": "www.example.com",
    "stage": "prod",
}]

connection keeps asyncssh's own option names, so port, password, passphrase, proxy_command and the rest pass straight through; address, username and key_path are friendly aliases for the target, the login name and a single identity key. Add more dictionaries to the list to add more hosts — run(REAL, deploy) fans the same deploy across all of them in parallel.

Two things change when you leave the container:

• Elevation. The beta examples run as the container's root, so they omit sudo. A real login user is not root, so pass sudo=True on each request that writes a system path — exactly as website_4.py and the prod snippets here do. Reemote renders sudo <command> and never prompts: grant the login user passwordless sudo, and set any run-as user or password in the entry's top-level privilege block (sudo_user, sudo_password), never in the operation.
• Reachability. Host-key checking is on by default; for a first connection to a new host either pre-seed ~/.ssh/known_hosts or pass "known_hosts": None in connection to skip the check.

Swap INVENTORY for REAL in any example and it deploys to your server instead of beta — the generator functions are identical, because a connector only overrides the transport, never the deploy.

Installing nginx

Both websites run behind nginx, so install it first. This is the shared base every host gets:

from reemote import apt, files, op

def nginx_base(host):
    yield op(apt.update, name="apt update")
    yield op(apt.packages, name="install nginx", packages=("nginx",))
    yield op(files.link, name="disable default site",
             path="/etc/nginx/sites-enabled/default", present=False)

Run it against beta and the plan and log line up. Verified output, first run:

== plan ==
beta: apt update               [changed: apt update]
beta: install nginx            [changed: 1 package(s) to install]
== log ==
beta: apt update               [changed: apt update]
    $ apt-get update
beta: install nginx            [changed: 1 package(s) to install]
    $ DEBIAN_FRONTEND=noninteractive apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install nginx

Run it again and it converges — except apt.update, which is deliberately stateless and always runs (there is no cache_time stamp file, because a timestamp would drift between the prepare and apply phases and break the determinism guard). Verified second run:

== plan ==
beta: apt update               [changed: apt update]
beta: install nginx            [no change: all packages present]
== log ==
beta: apt update               [changed: apt update]
    $ apt-get update
beta: install nginx            [no change: all packages present]

Disabling the default "Welcome to nginx!" site removes a symlink, and its plan reports exactly that. Verified output:

== plan ==
beta: disable default site     [changed: /etc/nginx/sites-enabled/default present, will remove]
== log ==
beta: disable default site     [changed: /etc/nginx/sites-enabled/default present, will remove]
    $ rm -f /etc/nginx/sites-enabled/default

Notice the ordering worked without any special handling. "Disable the default site" depends on nginx having created that symlink — and it did, because apply runs in lockstep, one request index at a time, so the install completes before the link step reads its fact. You might be tempted to gate the link on a fact instead:

# Do NOT do this — it cannot work, and reemote will not let it.
if some_link_fact:            # a live fact read inside the deploy body
    yield op(files.link, ...)

That branch reads a fact during prepare, when nginx is not installed yet, so the symlink would not exist and the step would be skipped on the very first run. Reemote forecloses the mistake entirely: branching on a live fact in a deploy raises DeterminismError. The lockstep apply is what makes "install, then configure what the install created" safe to write as two plain steps in order.

A config change usually needs a reload. Reemote has no notify/handler keyword; a conditional reload is built from the results of a previous run, in ordinary Python, between two deploys — the two-deploy split:

from reemote import changed_hosts, op, run, systemd

# Pass 1: converge the nginx config (the "notifying" tasks).
_, report, _ = await run(BETA, nginx_base)

# Freeze the hosts whose named operations actually changed.
changed = changed_hosts(report, {"disable default site"})

# Pass 2: reload nginx, only on those hosts.
def reload_nginx(host):
    if host.name in changed:
        yield op(systemd.service, name="reload nginx",
                 service="nginx", reloaded=True, sudo=True)

await run(BETA, reload_nginx)

changed is a fixed value by the time pass 2 builds its deploy, so the branch is on a snapshot — never a live fact — and stays deterministic. An empty changed yields an empty deploy: no host reloads. This is the whole notification mechanism, and it needs no handler-ordering rules to memorise.

!!! note "systemd needs a real init"

The reload above (and the service steps later) drive `systemctl`, which a
stock `ubuntu:24.04` container does not run as PID 1 — `systemctl` refuses
with "System has not been booted with systemd as init system". The
apt/files/user output in this article is verified against the container;
the systemd steps are shown as the code and the plan/log a systemd-enabled
host (a real VM, bare metal, or a `jrei/systemd-ubuntu` image) renders. On
production this just works.

Static site + code reuse

With nginx installed, the landing page is next. Keep its operations in a reusable function and include it conditionally, so a host only gets a site if its inventory says so:

def deploy(host):
    yield from nginx_base(host)
    if host.extra.get("home_domain"):
        yield from sub_deploy(home_site, name_prefix="home")(host)

host.extra is static inventory data, so this if is deterministic — both phases resolve it the same way. sub_deploy(..., name_prefix="home") labels every request the sub-deploy yields with a home: prefix, which is how the plan keeps a composed deploy readable.

Two honest adaptations from a YAML-and-Jinja workflow:

• There is no files.sync and no controller-filesystem awareness. Reemote never resolves a local directory path on the target's behalf; content crosses as data. To publish a folder of static files, read them control-side and install each one:

  from pathlib import Path
  from reemote import files, op
  
  def home_site(host):
      root = Path("site")                       # read on the control machine
      for path in sorted(root.rglob("*")):
          if path.is_file():
              rel = path.relative_to(root)
              yield op(files.install, name=f"install {rel}",
                       dest=f"/var/www/home/{rel}",
                       content=path.read_text(), sudo=True)
  

• There is no files.template. Jinja rendering happens control-side, in plain Python, and the resulting string goes to files.install. That keeps an unhashable template context out of the request (which must stay hashable) and needs no templating dependency.

For a single landing page, files.install writes the text and compares content, so a re-run is a no-op. Verified output — first run, then the identical run again:

== plan ==
beta: install landing page     [changed: content /var/www/html/index.html is absent, will install]
== log ==
beta: install landing page     [changed: content /var/www/html/index.html is absent, will install]
    $ scp <files install> -> /tmp/reemote-install-0c941e79a0742ece/content
    $ sh -c 'mkdir -p /var/www/html && cp /tmp/reemote-install-0c941e79a0742ece/content /var/www/html/index.html && chmod 644 /var/www/html/index.html && rm -rf /tmp/reemote-install-0c941e79a0742ece'

== plan ==
beta: install landing page     [no change: content already up to date (/var/www/html/index.html)]
== log ==
beta: install landing page     [no change: content already up to date (/var/www/html/index.html)]

The applied log shows the spool-and-install pattern reemote uses for root-owned files: an unprivileged scp of the text to a /tmp spool (named after the destination's hash, so it is stable across phases and never collides), then one elevated sh -c that copies it into place, sets the mode, and removes the spool. Nothing ever runs sed -i on a protected file. And now we have a static site.

Web app + secrets

The application is a small Flask app served by gunicorn behind nginx on a Unix socket:

:80, :443
   |
.-------------.
|    nginx    |  groups: app-socket, www-data
'-------------'
   |
 app.sock     groups: app-socket
   |
.- gunicorn --.
|   web app   |  groups: app-socket, app
'-------------'

Users and groups

nginx and gunicorn share the socket through a group, so create the accounts first:

def app_users(host):
    yield op(server.group, name="create app group", group="app")
    yield op(server.group, name="create socket group", group="app-socket")
    yield op(server.user, name="create app user", user="app", group="app",
             groups=("app-socket",), home="/var/lib/app",
             shell="/usr/sbin/nologin", system=True)

Verified output:

== plan ==
beta: create app group         [changed: group app absent, will create]
beta: create socket group      [changed: group app-socket absent, will create]
beta: create app user          [changed: user app absent, will create; home /var/lib/app missing, will create]
== log ==
beta: create app group         [changed: group app absent, will create]
    $ groupadd app
beta: create socket group      [changed: group app-socket absent, will create]
    $ groupadd app-socket
beta: create app user          [changed: user app absent, will create; home /var/lib/app missing, will create]
    $ useradd -d /var/lib/app -s /usr/sbin/nologin -g app -G app-socket -r -M app
    $ mkdir -p /var/lib/app
    $ chown app:app /var/lib/app

Give nginx access to the socket by appending www-data to the group — server.user(user="www-data", groups=("app-socket",), append=True). groups is a tuple, not a list, for the same hashability reason as packages.

The virtual environment

Reemote ships no pip module, so the venv is a custom operation — an async generator that reads a fact and yields a command, exactly like the built-ins:

from reemote import OpContext, StringCommand
from reemote.modules.files.files import FileExists

async def venv(ctx: OpContext, path: str, python: str = "python3"):
    """Ensure a virtualenv exists at ``path``."""
    if await ctx.facts.get(FileExists, f"{path}/bin/python"):
        ctx.reason = f"venv {path} already exists"
        return
    ctx.changed = True
    ctx.reason = f"venv {path} missing, will create"
    yield StringCommand(f"{python} -m venv {path}")

async def pip_install(ctx: OpContext, venv_path: str, packages: tuple[str, ...]):
    """Install packages into a venv (kept simple: always runs)."""
    ctx.changed = True
    ctx.reason = f"install {len(packages)} package(s) into {venv_path}"
    yield StringCommand(f"{venv_path}/bin/pip install {' '.join(packages)}")

Writing a custom operation is this little code, which is the offset reemote offers for a smaller built-in catalogue. A production pip_install would read pip freeze as a fact and skip work when the requirement is already satisfied; the version above is deliberately minimal. Use them like any built-in: yield op(venv, name="create venv", path="/opt/app").

Publish the application source the same control-side way as the static files, then install it into the venv. The systemd unit is text, so it is files.install again, and the service is systemd.service:

def app_service(host):
    yield op(files.install, name="write app.service",
             dest="/etc/systemd/system/app.service",
             content=render_unit(host), sudo=True)
    yield op(systemd.service, name="run app", service="app",
             running=True, enabled=True, daemon_reload=True, sudo=True)

On a systemd-enabled host, a first run renders (from the module's own reason strings — start is yielded before enable):

== plan ==
web2: run app                  [changed: app.service not running (inactive), will start; app.service not enabled, will enable]
== log ==
web2: run app                  [changed: app.service not running (inactive), will start; app.service not enabled, will enable]
    $ sudo systemctl start app.service
    $ sudo systemctl enable app.service

...and converges on a re-run to [no change: app.service already running; app.service already enabled]. When the code changes you want a restart, which is the two-deploy split again — and reemote ships the helper for the common case:

from reemote import changed_hosts, restart_handler, run

_, report, _ = await run(PROD, app_deploy)          # pass 1: publish code + config
changed = changed_hosts(report, {"write app config", "write app.service"})  # config or unit changed?
await run(PROD, restart_handler(changed, "app"))     # pass 2: restart only those

Secrets

Flask needs a SECRET_KEY, and it should differ between beta and prod. A deploy is Python, so read the secret from wherever you keep it — a password manager, a hardware key, an encrypted file. To illustrate, a function that reads named secrets from a JSON file, keyed by stage:

import json
from pathlib import Path

def get_secret(name, stage):
    data = json.loads(Path("secrets.json").read_text())
    if secret := data.get(stage, {}).get(name):
        return secret
    raise RuntimeError(f"secret {name!r} for stage {stage!r} not found")

The stage comes from host.extra["stage"] — set per host in the inventory, not hardcoded. Render the config control-side and install it, owned by the app group and mode 0640:

def app_config(host):
    stage = host.extra.get("stage", "beta")
    secret = get_secret("app_secret_key", stage)
    content = f"SECRET_KEY = {secret!r}\n"
    yield op(files.install, name="write app config",
             dest="/etc/opt/app/config.py", content=content,
             group="app", mode="0640", sudo=True)

!!! warning "A restrictive mode costs you content idempotence"

`files.install` decides whether to write by reading the destination back —
unprivileged, as the login user. A file installed `0640` and owned by a
service account cannot be read by that login user, so it reads back empty
and re-installs on **every** run. Content idempotence needs a
login-readable file. Either install the secret `0644` (world-readable —
usually not what you want for a key), or accept the re-write, or keep the
secret out of a file the login user cannot read. This is a real, documented
trade-off, not a bug — plan the mode with it in mind.

Where you store the secret is up to you; reading an unencrypted JSON file is the simple-and-wrong baseline, exactly as hardcoding it would be. Use an encrypted store in production.

HTTPS + prod

A web app is nicer when it is not "not secure". Let's Encrypt gives free certificates and Certbot requests, installs, and renews them. Reemote has no built-in Certbot operation, so write one — a fact to read the current certificates and an operation to request a missing one:

from reemote import OpContext, StringCommand

class Certificates:
    """The set of domain names certbot already has certificates for."""
    @classmethod
    async def process(cls, host):
        out = await host.run_shell("certbot certificates")
        return _parse_certbot_names(out)          # -> set[str]

async def certificate(ctx: OpContext, domain: str):
    """Request a certificate for ``domain`` if certbot does not have one."""
    if domain in await ctx.facts.get(Certificates):
        ctx.reason = f"certificate for {domain} already present"
        return
    ctx.changed = True
    ctx.reason = f"certificate for {domain} missing, will request"
    yield StringCommand(f"certbot certonly -d {domain} -n --nginx --agree-tos")

A fact is any class with an async process classmethod; an operation is any async generator taking an OpContext. Read state with the fact, yield a command only when it does not match — the same shape as every built-in. Install Certbot itself with apt.packages(packages=("python3-certbot-nginx",)) first, and the site sub-deploy gains one conditional step:

def nginx_site(host, template, domain, https=False):
    if https:
        yield op(certificate, name="cert", domain=domain, sudo=True)
    yield op(files.install, name="write site",
             dest=f"/etc/nginx/sites-available/{domain}",
             content=render_site(template, domain, https), sudo=True)
    yield op(files.link, name="enable site",
             path=f"/etc/nginx/sites-enabled/{domain}",
             target=f"/etc/nginx/sites-available/{domain}", sudo=True)

Certbot needs a resolvable domain name to complete the HTTP-01 challenge, so this cannot be exercised against the local beta container — but it can always be tested in production. The prod inventory is two SSH hosts, each with its own domain and HTTPS switched on through host.extra:

PROD = [
    {"host": "web1",
     "connection": {"address": "web1.example.com", "username": "deploy",
                    "key_path": "~/.ssh/id_ed25519"},
     "home_domain": "www.example.com", "stage": "prod", "nginx_https": True},
    {"host": "web2",
     "connection": {"address": "web2.example.com", "username": "deploy",
                    "key_path": "~/.ssh/id_ed25519"},
     "app_domain": "app.example.com", "stage": "prod", "nginx_https": True},
]

There is no --yes flag to skip a prompt, because there is no prompt. Preview the whole fleet with dry=True — a real prepare pass against live facts on both servers, changing nothing — then run it for real:

plans, _, _ = await run(PROD, deploy, dry=True)     # look
print(format_plan(plans))

plans, report, _ = await run(PROD, deploy)          # leap
print(format_log(report))

sudo=True on the requests is the whole elevation story on Ubuntu: reemote renders sudo <command> and never needs an interactive password prompt — use passwordless sudoers or a login user with NOPASSWD, and the run-as user and any password come from the inventory's privilege block, never from the operation. A minute later there are two new websites on the internet, and the identical deploy — the same generator functions — produced both, differing only in the inventory it was handed.

Questions?

Can I use reemote from an interactive Python shell? Yes — it is a library, so await run(inventory, deploy) works in a REPL, a notebook, or asyncio.run(...). There is a little boilerplate (building the inventory, wrapping the async call), and no CLI sugar to load inventories for you; that is the trade for it being importable.

Can I use reemote to provision cloud resources? No — use Terraform for that. Reemote configures machines over SSH (or inside containers); it does not create or destroy infrastructure. Staying "commands over a connection" is a deliberate scope. And if you find you need fewer resources than you thought, one well-built machine goes a long way.

Can I use reemote with cloud inventories? Yes. The inventory is a Python list, so build it from your cloud's SDK directly — listing the instances in an autoscaling group is a few lines. There is no separate dynamic-inventory plugin to configure; it is just an expression that evaluates to a list of dicts.

What about the connectors? This article used two: the default ssh connector for production, and the docker connector for the local beta container. The same deploy runs against either, because a connector only overrides the transport seams (run a command, copy a file) — you pick it per inventory entry, never in the deploy.

Try it

• Documentation and full guide: https://reemote.org/
• Source: https://github.com/kimjarvis/reemote
• PyPI: pip install reemote
• License: EPL-2.0

The problem: configuration management on CentOS

CentOS — and the RHEL family it anchors: Rocky, Alma, Fedora Server — runs a huge share of enterprise fleets, a lot of cPanel/hosting infrastructure, and most on-prem boxes that were "standardised on Red Hat" a decade ago and never moved. Its shape is well known and Ansible handles it cleanly, but the pain is not "can the tool talk to the box". It is everything a CLI-shaped tool costs you once you want to embed deployment in a Python program.

That is the gap: there is no serious configuration-management library you can import and point at a CentOS box. Reemote is that library, and the RHEL family is where its dnf namespace feels most at home — application streams, repo files, and rpm's GPG keyring all ship as first-class facts and operations, alongside the same two-phase prepare-then-apply runner everything else uses.

Try it in under a minute (docker connector)

Reemote ships a docker connector that runs your deploy inside a local container, so you need neither a remote host nor an SSH key to see it work. You do need Docker or Podman installed locally — the connector shells out to whichever CLI you name, and there is no default. Three commands:

# 1. install reemote into a fresh venv (Python 3.13+; pip works just as well as uv)
uv venv .venv && source .venv/bin/activate && uv pip install reemote
# 2. save the script below as centos_demo.py
# 3. run it — starts a throwaway CentOS Stream 9 container, configures it, cleans up
python centos_demo.py

# centos_demo.py
import asyncio
from reemote import dnf, format_log, format_plan, op, run

INVENTORY = [{
    "host": "centos-demo",
    "connection": {
        "connector": "docker",
        "identifier": "quay.io/centos/centos:stream9",
        "docker_cmd": "podman",   # or "docker"
    },
}]

def deploy(host):
    # The most common first task after dropping onto a fresh CentOS server:
    # install the web server the RHEL family ships as its default — httpd.
    yield op(dnf.packages,
             name="Install httpd",
             packages=("httpd",))

async def main():
    plans, report, _ = await run(INVENTORY, deploy)
    print("== Plan ==")
    print(format_plan(plans))
    print("== Applied ==")
    if report is not None:
        print(format_log(report))

asyncio.run(main())

Verified output:

== Plan ==
centos-demo: Install httpd [changed: 1 package(s) to install]
== Applied ==
centos-demo: Install httpd [changed: 1 package(s) to install]
    $ dnf install -y httpd

Three things worth noticing, because they are exactly where CentOS + Reemote differ from CentOS + Ansible:

• No YAML, no Jinja2, no ansible.builtin.dnf. dnf.packages is a Python function your editor knows: go-to-definition, autocomplete, type check. The packages= argument is a tuple because operation kwargs must stay hashable — the same determinism rule that lets reemote run your deploy twice (once to plan, once to apply) and prove both passes agree.
• No -y to remember. The dnf namespace knows its own non-interactive vocabulary and renders dnf install -y httpd for you. Reemote exposes dnf's own idioms rather than flattening them into a lowest-common-denominator package API — the same shape apt.packages takes on Ubuntu and apk.no_cache on Alpine.
• A full-system upgrade is a different word here. On Ubuntu apt-get update just refreshes the package lists; on CentOS dnf update upgrades every package. That is why this quickstart installs one package and stops. To refresh metadata without upgrading, use dnf.makecache; to actually patch the box, use dnf.update — reemote spells each one explicitly rather than collapsing them into one ambiguous update= flag.

One honesty note, the same one the throwaway-container workflow always carries: every run reports [changed: ...], even the second time, because the image target starts a fresh centos:stream9 container on each invocation, so httpd genuinely is absent each time. Point reemote at a stable target — an SSH host, or an existing container ID — and the second run correctly reports [no change: all packages present]. You will see exactly that below.

Why Python has real advantages over Ansible

Ansible chose YAML because it is readable and does not require knowing a programming language. That is a fair trade when your team does not write Python. When it does — and most automation teams today do — the trade costs more than it saves:

• Your editor knows your code. dnf.packages and systemd.service are functions: go-to-definition, rename, autocomplete, and a type check that catches a typo before it reaches a production box. A misspelled YAML module name surfaces at runtime, in the middle of a rollout.
• No Jinja2 as a second language. {{ hostvars[...] }} is a stringly-typed escape hatch that fights your IDE and your tests. In reemote the value is just a Python expression, evaluated by the interpreter you already trust.
• Composition is import, not directory layout. Ansible roles load by convention (tasks/main.yml, defaults/main.yml, handlers/main.yml); reemote deploys are generators you import, call, and loop over.
• The result is data, not stdout. If your application needs to know what changed, you read report.entries[i].changed — you do not regex-scrape a terminal, and you do not depend on callback_plugins to reshape the log for you.
• Testing is pytest. A deploy function is a pure generator; you can inspect the requests it yields without touching a server. No molecule, no testinfra, no ansible-lint.
• await is your concurrency model. Hosts progress in parallel because the transport is asyncssh, not because a CLI forked worker processes you have to configure.

The solution: Reemote is a library

Reemote is a Python package (pip install reemote) with two properties that separate it from every CLI-shaped tool.

Async end to end, on asyncssh

The transport is asyncssh, and the entire execution path — connecting, gathering facts, sending commands, closing — is coroutines. You await a deploy and hosts progress in parallel; network waits overlap across hosts while each host's commands stay in order. Your deploy script remains a plain synchronous generator, so you never write async inside an operation.

plans, report, hosts = await run(inventory, deploy)

run is the single entry point: it validates the inventory, opens connections lazily, plans and applies in two phases, then closes everything in a finally. The same code runs over SSH or over the docker connector — you pick the transport in the inventory entry, not in the deploy. That is why you can develop a CentOS role against a local container and ship it to a VM without changing a line.

A library returning structured results, not a CLI

run(...) returns (plans, report, hosts):

• plans — {host_label: [PlannedOperation, ...]}, the proposed work per host.
• report — an ApplyReport with a LogEntry per applied operation, each carrying changed, reason, and the exact commands sent. None when dry=True.
• hosts — the materialised host objects.

format_plan and format_log (what you saw above) are convenience renderers for humans. Your application consumes the objects directly — no parsing stdout to figure out what happened, no --check mode plus a callback plugin to reconstruct the plan after the fact.

The dnf module: CentOS's package manager as Python

dnf pairs read-only facts with operations that converge the box toward a described state. An operation reads a fact, decides whether anything must change, and yields commands only when it must — so re-running against a stable target is a no-op. The non-idempotent verbs (update, makecache, clean, and the key-import direction) are the deliberate exceptions, and each is documented as such.

The operations cover the whole package lifecycle, in dnf's own vocabulary rather than a lowest-common-denominator one: install/upgrade/remove by name (dnf.packages), a full-system upgrade (dnf.update), metadata refresh and cache cleanup (dnf.makecache, dnf.clean), repository-file management (dnf.repo), GPG-key import and removal on the rpm keyring (dnf.key), local .rpm file installs (dnf.rpm), and the RHEL-only application/module streams (dnf.module). Most read a fact and yield commands only when the box differs from the request, so re-running against a stable target is a no-op; a few verbs — update, makecache, clean, and the key-import direction — are deliberately non-idempotent, because there is no cheap fact that predicts whether they would change anything.

The facts are the read side of the same vocabulary: which packages (and which versions) are installed, which repositories are configured and what their .repo files contain, which module streams are enabled/disabled/installed, which package groups exist, the version of a local .rpm, and which GPG keys sit in the rpm keyring. Every enumerating fact returns sorted, de-duplicated, JSON-printable typed entries — not a scraped string — so a read is data you can diff, log, or assert on.

The systemd module: CentOS's init as Python

systemd manages services along two independent axes: whether a unit is running right now, and whether it is enabled at boot. A unit can be enabled but stopped, or running but not enabled. systemd.service handles both in one operation, and the namespace goes well beyond services — drop-ins, timers, tmpfiles, sysusers, masking, presets. It is the same module Ubuntu uses; the RHEL family is where systemd was born, so nothing here is a portability compromise.

The operations center on systemd.service — one call that manages a unit along both axes (running and enabled) plus the restart/reload verbs — and extend to the surrounding unit-file machinery: an explicit daemon_reload, drop-ins, tmpfiles.d/sysusers.d config files, masking, presets, and clearing a failed state. The state-changing verbs read a fact first and yield a systemctl command only on a difference, so they are idempotent; restart, reload, and daemon-reload are the intentional non-idempotent exceptions.

The facts answer both the per-unit questions (is it running? enabled? what are its properties, dependencies, or unit-file path?) and the whole-system audit questions (what is failed? what timers are scheduled? what is the system state? which systemd version?). Several are reemote originals that expose the audit view the baseline never surfaced, and every systemctl-based fact and operation takes scope flags for the per-user manager or a named machine.

Install a package, then ensure its service — verified

The classic CentOS post-install move is install the daemon, then enable and start it — httpd for a web tier. In reemote that is dnf.packages followed by systemd.service, composed in one deploy:

def deploy(host):
    # 1. Install httpd (ships /usr/lib/systemd/system/httpd.service).
    yield op(dnf.packages,
             name="Install httpd",
             packages=("httpd",),
             sudo=True)
    # 2. Enable and start its systemd unit.
    yield op(systemd.service,
             name="Run httpd",
             service="httpd",
             running=True,
             enabled=True,
             sudo=True)

The ordering is the point. The apply phase runs in lockstep — one request index at a time across all hosts — so every host finishes the install before any host begins the service step. The systemd.service request therefore always sees the httpd.service unit file the install just delivered. There is no combined "ensure" operation to maintain; the two halves compose, and each is idempotent against its own facts.

First run against a CentOS host with systemd as PID 1:

== Plan ==
centos-demo: Install httpd [changed: 1 package(s) to install]
centos-demo: Run httpd     [changed: httpd.service not running (inactive), will start; httpd.service not enabled, will enable]
== Applied ==
centos-demo: Install httpd [changed: 1 package(s) to install]
    $ sudo dnf install -y httpd
centos-demo: Run httpd     [changed: httpd.service not running (inactive), will start; httpd.service not enabled, will enable]
    $ sudo systemctl start httpd.service
    $ sudo systemctl enable httpd.service

Run the identical script again against the same host and it converges — this is the [no change: ...] the throwaway quickstart could not show:

== Plan ==
centos-demo: Install httpd [no change: all packages present]
centos-demo: Run httpd     [no change: httpd.service already running; httpd.service already enabled]
== Applied ==
centos-demo: Install httpd [no change: all packages present]
centos-demo: Run httpd     [no change: httpd.service already running; httpd.service already enabled]

Two CentOS-specific honesty notes:

• The stock centos:stream9 container image does not run systemd as PID 1 — systemctl start/enable refuse to operate with "System has not been booted with systemd as init system". The quickstart at the top deliberately sticks to dnf.packages for exactly that reason. To exercise the systemd half locally, use a systemd-capable image or your own docker run --privileged ... /sbin/init recipe; on a real CentOS VM or bare-metal host systemd is PID 1 and everything above just works.
• sudo is uniform on CentOS. The RHEL family ships sudo preinstalled, so sudo=True on a request is the whole elevation story. Reemote renders sudo <command> on the descriptor and never needs a password prompt: use passwordless sudoers, or an SSH key for a login user with NOPASSWD, or su=True if you would rather reemote escalate through su (root logins are common on legacy CentOS boxes).

A day-one CentOS playbook, in Python

Here is the routine post-install set — the tasks a CentOS playbook always opens with — as one reemote deploy. No YAML, no Jinja2, no handlers section:

def deploy(host):
    # (1) Patch the box. On the RHEL family `dnf update` is a full-system
    #     upgrade — the literal "yum update" every CentOS admin runs first.
    yield op(dnf.update, name="Apply pending updates", sudo=True)

    # (2) Baseline tooling every CentOS server wants.
    yield op(dnf.packages, name="Install baseline tools",
             packages=("curl", "git", "htop"),
             sudo=True)

    # (3) Web tier: install httpd, then enable and start it.
    yield op(dnf.packages, name="Install httpd",
             packages=("httpd",), sudo=True)
    yield op(systemd.service, name="Run httpd", service="httpd",
             running=True, enabled=True, sudo=True)

    # (4) Time sync — chrony is the RHEL-family default NTP client, and its
    #     unit is chronyd (not Debian's chrony).
    yield op(dnf.packages, name="Install chrony",
             packages=("chrony",), sudo=True)
    yield op(systemd.service, name="Run chronyd", service="chronyd",
             running=True, enabled=True, sudo=True)

    # (5) Application streams — a RHEL-only concept: pin nginx to the 1.24
    #     stream so a later `dnf install nginx` resolves that version.
    yield op(dnf.module, name="Enable nginx:1.24 stream",
             module="nginx", stream="1.24", sudo=True)

    # (6) Hardening: a drop-in that tightens sshd, then a reload — the
    #     "handler" is just the next request in the same generator.
    yield op(systemd.dropin, name="Harden sshd",
             filename="10-reemote.conf", unit="sshd.service",
             content="[Service]\nPermitRootLogin=no\n",
             sudo=True)
    yield op(systemd.daemon_reload, name="Reload systemd after drop-in",
             sudo=True)
    yield op(systemd.service, name="Restart sshd", service="sshd",
             restarted=True, sudo=True)

Task (6) is the one that shows off the library shape most. In Ansible the drop-in is a template plus a notify: restart sshd handler, and the handler fires only if the template reported changed. In reemote the "handler" is ordinary Python: run the config deploy, read its report, freeze the set of hosts that actually changed with reemote.handlers.changed_hosts, and feed that set into a second deploy that calls systemd.service("sshd", restarted=True). No notify keyword, no handler-ordering rules to memorise — just the structured result you already have.

What follows: Reemote can manage CentOS instead of Ansible

Once configuration management is a library, everything Python already has becomes available to your CentOS deploys:

• Deploy from your application. await run(inventory, deploy) inside a FastAPI handler, a Celery task, a Python GitHub Action, or a REPL.
• Compose with real code. Build the inventory from a database query; generate .repo file text or daemon.json from a Pydantic model; share validation between the app and the deploy.
• Test with pytest. Deploy functions are pure generators — assert on the requests they yield without a server in sight.
• Consume structured results. report.entries[i].changed, .reason, .commands are data you can log, chart, feed to a webhook, or gate a rollout on.
• Two-phase execution for free. Every run prepares then applies; dry=True is a real preview against live facts, not a simulation.
• Same code over SSH or Docker. Flip the connector key and the identical deploy runs against a CentOS VM or a local container — test the role before you point it at production, or build an image from the same code that configures a host.
• Handlers as ordinary Python. Read the first deploy's report, freeze the changed hosts, feed them into a second deploy. changed_hosts and restart_handler ship for the common case.

You can use reemote instead of Ansible whenever managing CentOS is part of a Python program rather than a shell command in a CI job — which, for most teams building products today, is the more natural shape. And on the RHEL family specifically, you keep dnf's own vocabulary intact — module streams, repo files, the rpm keyring — rather than flattening it through a lowest-common-denominator module API.

What Reemote is not

• Not a deployment CLI. There is no reemote command; you write the script.
• Not an inventory format. Inventory is a Python list of dicts — load it from JSON, YAML, a database, or write it inline.
• Not a role ecosystem. Reemote ships modules for dnf, systemd, apt, apk, openrc, files, server, git, mysql, postgresql, iptables, firewalld, ufw, selinux, lxd, snap, flatpak, sysctl, gpg, and hardware — but there is no Ansible Galaxy equivalent.
• Not a download tool. Reemote never fetches a URL mid-run: dnf.repo, dnf.rpm, and dnf.key all reject a URL src by design. Fetch control-side (optionally checksum-verified) and stream the bytes in.
• Not a translation layer between OSes. Python does not make httpd installable by the same name on CentOS and Ubuntu, nor make dnf update mean the same as apt-get update. You still pick the right module for the target — and on CentOS that means dnf and systemd, which reemote ships as first-class citizens.

Try it

• Documentation and full guide: https://reemote.org/
• Source: https://github.com/kimjarvis/reemote
• PyPI: pip install reemote
• License: EPL-2.0

If you have ever wanted to describe a CentOS box's state in the same language as the rest of your stack — with imports, types, tests, and await, and without translating dnf's and systemd's vocabularies through YAML — the docker quickstart at the top of this article is the whole onboarding. Give it a minute.

The problem: configuration management on Ubuntu

Ubuntu is what most cloud VMs, most CI runners and a large share of internal fleets boot into. Its shape is well known and Ansible handles it cleanly — but the pain is not "can the tool talk to the box". It is everything the tool-shaped-like-a-CLI costs you once you want to embed deployment in a Python program:

• apt, not apk or dnf. A whole vocabulary of its own — apt-get update, apt-get install, apt-mark hold, apt-add-repository, sources.list.d/*.sources deb822 files, /etc/apt/keyrings/ for signed-by=.
• systemd, the init every modern Linux converged on — services along two independent axes (running right now, enabled at boot), plus drop-ins, timers, tmpfiles.d, sysusers.d, masking, presets.
• sudo preinstalled, so elevation is uniform. Python 3 preinstalled, so Ansible's usual bootstrap dance does not apply here — but every other cost of a CLI-shaped tool does: YAML plus Jinja2, roles loaded by directory convention, results scraped from stdout, tests written in testinfra/molecule rather than pytest, and no way to await a deploy from inside your own application.

That is the gap: there is no serious configuration-management library you can import and point at an Ubuntu box. Reemote is that library, and Ubuntu is where it feels most at home — apt and systemd ship as first-class namespaces with facts, operations, and the same two-phase prepare-then-apply runner everything else uses.

Try it in under a minute (docker connector)

Reemote ships a docker connector that runs your deploy inside a local container, so you need neither a remote host nor an SSH key to see it work. You do need Docker or Podman installed locally — the connector shells out to whichever CLI you name, and there is no default. Three commands:

# 1. install reemote into a fresh venv (Python 3.13+; pip works just as well as uv)
uv venv .venv && source .venv/bin/activate && uv pip install reemote
# 2. save the script below as ubuntu_demo.py
# 3. run it — starts a throwaway ubuntu:24.04 container, configures it, cleans up
python ubuntu_demo.py

# ubuntu_demo.py
import asyncio
from reemote import apt, format_log, format_plan, op, run

INVENTORY = [{
    "host": "ubuntu-demo",
    "connection": {
        "connector": "docker",
        "identifier": "ubuntu:24.04",
        "docker_cmd": "podman",   # or "docker"
    },
}]

def deploy(host):
    # The most common first task after dropping onto a fresh Ubuntu server:
    # refresh the package lists and install nginx.
    yield op(apt.packages,
             name="Install nginx",
             packages=("nginx",),
             update=True)

async def main():
    plans, report, _ = await run(INVENTORY, deploy)
    print("== Plan ==")
    print(format_plan(plans))
    print("== Applied ==")
    if report is not None:
        print(format_log(report))

asyncio.run(main())

Verified output:

== Plan ==
ubuntu-demo: Install nginx [changed: 1 package(s) to install]
== Applied ==
ubuntu-demo: Install nginx [changed: 1 package(s) to install]
    $ apt-get update
    $ DEBIAN_FRONTEND=noninteractive apt-get -y install nginx

Three things worth noticing, because they are exactly where Ubuntu + Reemote differ from Ubuntu + Ansible:

• No YAML, no Jinja2, no ansible.builtin.apt. apt.packages is a Python function your editor knows: go-to-definition, autocomplete, type check. The packages= argument is a tuple because operation kwargs must stay hashable — the same determinism rule that lets reemote run your deploy twice (once to plan, once to apply) and prove both passes agree.
• No -y to remember, no DEBIAN_FRONTEND to export. The apt namespace knows its own non-interactive vocabulary and renders it for you. Reemote exposes apt's own idioms rather than flattening them into a lowest-common-denominator package API — the same shape apk.no_cache takes on Alpine.
• update=True is a stateless prefix. It always runs apt-get update before the install, exactly like the baseline's apt.update; there is no cache_time stamp file, deliberately, because the stamp would drift between the prepare and apply phases and break the determinism guard.

One honesty note, the same one the throwaway-container workflow always carries: every run reports [changed: ...], even the second time, because the image target starts a fresh ubuntu:24.04 container on each invocation, so nginx genuinely is absent each time. Point reemote at a stable target — an SSH host, or an existing container ID — and the second run correctly reports [no change: all packages present]. You will see exactly that below.

Why Python has real advantages over Ansible

Ansible chose YAML because it is readable and does not require knowing a programming language. That is a fair trade when your team does not write Python. When it does — and most automation teams today do — the trade costs more than it saves:

• Your editor knows your code. apt.packages and systemd.service are functions: go-to-definition, rename, autocomplete, and a type check that catches a typo before it reaches a production box. A misspelled YAML module name surfaces at runtime, in the middle of a rollout.
• No Jinja2 as a second language. {{ hostvars[...] }} is a stringly-typed escape hatch that fights your IDE and your tests. In reemote the value is just a Python expression, evaluated by the interpreter you already trust.
• Composition is import, not directory layout. Ansible roles load by convention (tasks/main.yml, defaults/main.yml, handlers/main.yml); reemote deploys are generators you import, call, and loop over.
• The result is data, not stdout. If your application needs to know what changed, you read report.entries[i].changed — you do not regex-scrape a terminal, and you do not depend on callback_plugins to reshape the log for you.
• Testing is pytest. A deploy function is a pure generator; you can inspect the requests it yields without touching a server. No molecule, no testinfra, no ansible-lint.
• await is your concurrency model. Hosts progress in parallel because the transport is asyncssh, not because a CLI forked worker processes you have to configure.

The solution: Reemote is a library

Reemote is a Python package (pip install reemote) with two properties that separate it from every CLI-shaped tool.

Async end to end, on asyncssh

The transport is asyncssh, and the entire execution path — connecting, gathering facts, sending commands, closing — is coroutines. You await a deploy and hosts progress in parallel; network waits overlap across hosts while each host's commands stay in order. Your deploy script remains a plain synchronous generator, so you never write async inside an operation.

plans, report, hosts = await run(inventory, deploy)

run is the single entry point: it validates the inventory, opens connections lazily, plans and applies in two phases, then closes everything in a finally. The same code runs over SSH or over the docker connector — you pick the transport in the inventory entry, not in the deploy. That is why you can develop an Ubuntu role against a local container and ship it to a VM without changing a line.

A library returning structured results, not a CLI

run(...) returns (plans, report, hosts):

• plans — {host_label: [PlannedOperation, ...]}, the proposed work per host.
• report — an ApplyReport with a LogEntry per applied operation, each carrying changed, reason, and the exact commands sent. None when dry=True.
• hosts — the materialised host objects.

format_plan and format_log (what you saw above) are convenience renderers for humans. Your application consumes the objects directly — no parsing stdout to figure out what happened, no --check mode plus a callback plugin to reconstruct the plan after the fact.

The apt module: Ubuntu's package manager as Python

apt pairs read-only facts with operations that converge the box toward a described state. An operation reads a fact, decides whether anything must change, and yields commands only when it must — so re-running against a stable target is a no-op.

The operations cover four kinds of apt work:

• Package lifecycle — install, upgrade, remove, autoremove, and hold by name, with exact-version pinning. Every mutation is idempotent against the installed-package fact; the whole-box upgrade verbs are additionally gated on a dry-run simulation, so a fully patched host is a genuine no-op rather than a shell-out that quietly does nothing.
• Repository configuration — legacy sources.list lines, modern deb822 .sources files, GPG keyrings under /etc/apt/keyrings/ for signed-by=, and Ubuntu PPAs. The file-managing operations all use a spool-and-install rewrite — read the current text, apply a pure transform, scp the result to /tmp, install it with one elevated sh -c — so comments, ordering, and unrelated lines survive verbatim and nothing ever runs sed -i on a protected file.
• Standalone .deb files — install or remove a package archive already on the target (upload one with files.put first), version-aware and idempotent.
• The stateless refresh — apt-get update as its own step, so the list-refresh is separately plannable from anything that consumes it.

The facts cover the same ground from the read side: what is installed, what would upgrade, what would autoremove, what is held back, which version apt install would pick and from which repository, which sources are configured (parsed from both the legacy and the deb822 formats), which keyrings are present, and what a dry-run apt-get proposes to change. Every list fact returns sorted, de-duplicated, JSON-printable typed entries — not a scraped string — so your application can consume them directly.

The systemd module: Ubuntu's init as Python

systemd manages services along two independent axes: whether a unit is running right now, and whether it is enabled at boot. A unit can be enabled but stopped, or running but not enabled. The systemd namespace handles both in one operation, and goes well beyond services.

The operations cover three kinds of systemd work:

• Unit state — one service operation converges running and enabled from their facts and yields systemctl start/stop/enable/disable only on a difference, alongside the non-idempotent verbs (restart, reload, reload-or-try-restart, reset-failed) for when you mean it. A separate daemon-reload operation keeps the reload step plannable on its own.
• Unit-file configuration — drop-ins under /etc/systemd/system/<unit>.d/, plus /etc/tmpfiles.d/*.conf and /etc/sysusers.d/*.conf. All three ride the same spool-and-install rewrite apt.repo uses, so the stock unit file stays pristine and every write is one unprivileged scp followed by one elevated sh -c.
• Unit policy — mask a unit to /dev/null so nothing can start it, apply the systemd preset policy, or clear failed state without also starting the unit.

The facts cover the audit view: per-unit running and enabled state, unit-file presence, unit properties and dependencies, failed units, scheduled timers, and the systemd version. Every systemctl-based fact and operation also accepts scope flags (user_mode, machine, user_name) for the per-user manager or a named machine, so the same code drives a system unit or a user unit.

Install a package, then ensure its service — verified

The classic Ubuntu post-install move is install the daemon, then enable and start it — nginx for a web tier, say. In reemote that is apt.packages followed by systemd.service, composed in one deploy:

def deploy(host):
    # 1. Install nginx (ships /lib/systemd/system/nginx.service).
    yield op(apt.packages,
             name="Install nginx",
             packages=("nginx",),
             update=True,
             sudo=True)
    # 2. Enable and start its systemd unit.
    yield op(systemd.service,
             name="Run nginx",
             service="nginx",
             running=True,
             enabled=True,
             sudo=True)

The ordering is the point. The apply phase runs in lockstep — one request index at a time across all hosts — so every host finishes the install before any host begins the service step. The systemd.service request therefore always sees the nginx.service unit file the install just delivered. There is no combined "ensure" operation to maintain; the two halves compose, and each is idempotent against its own facts.

First run against an Ubuntu host with systemd as PID 1:

== Plan ==
ubuntu-demo: Install nginx [changed: 1 package(s) to install]
ubuntu-demo: Run nginx     [changed: nginx.service not running (inactive), will start; nginx.service not enabled, will enable]
== Applied ==
ubuntu-demo: Install nginx [changed: 1 package(s) to install]
    $ sudo apt-get update
    $ sudo DEBIAN_FRONTEND=noninteractive apt-get -y install nginx
ubuntu-demo: Run nginx     [changed: nginx.service not running (inactive), will start; nginx.service not enabled, will enable]
    $ sudo systemctl start nginx.service
    $ sudo systemctl enable nginx.service

Run the identical script again against the same host and it converges — this is the [no change: ...] the throwaway quickstart could not show:

== Plan ==
ubuntu-demo: Install nginx [no change: all packages present]
ubuntu-demo: Run nginx     [no change: nginx.service already running; nginx.service already enabled]
== Applied ==
ubuntu-demo: Install nginx [no change: all packages present]
ubuntu-demo: Run nginx     [no change: nginx.service already running; nginx.service already enabled]

Two Ubuntu-specific honesty notes:

• The stock ubuntu:24.04 container image does not run systemd as PID 1 — systemctl start/enable refuse to operate with "System has not been booted with systemd as init system". The quickstart at the top deliberately sticks to apt.packages for exactly that reason. To exercise the systemd half locally, use a systemd-capable image (jrei/systemd-ubuntu:24.04 or your own docker run --privileged ... /sbin/init recipe); on a real Ubuntu VM or bare-metal host systemd is PID 1 and everything above just works.
• sudo is uniform on Ubuntu. Unlike Alpine (no sudo, only doas), Ubuntu ships sudo preinstalled and the first user is in the sudo group, so sudo=True on a request is the whole elevation story. Reemote renders sudo <command> on the descriptor and never needs a password prompt: use passwordless sudoers, or an SSH key for a login user with NOPASSWD, or su=True if you would rather reemote escalate through su.

A day-one Ubuntu playbook, in Python

Here is the routine post-install set — the tasks an Ubuntu playbook always opens with — as one reemote deploy. No YAML, no Jinja2, no handlers section:

def deploy(host):
    # (1) Patch the box: refresh lists, then upgrade everything the
    #     simulation says would move.
    yield op(apt.update, name="Refresh package lists", sudo=True)
    yield op(apt.upgrade, name="Apply pending upgrades", sudo=True)

    # (2) Baseline tooling every Ubuntu server wants.
    yield op(apt.packages, name="Install baseline tools",
             packages=("curl", "git", "htop", "unattended-upgrades"),
             sudo=True)

    # (3) Web tier: install nginx, then enable and start it.
    yield op(apt.packages, name="Install nginx",
             packages=("nginx",), sudo=True)
    yield op(systemd.service, name="Run nginx", service="nginx",
             running=True, enabled=True, sudo=True)

    # (4) Time sync — Ubuntu ships systemd-timesyncd already enabled;
    #     chrony is the drop-in when you need NTP-server behaviour.
    yield op(apt.packages, name="Install chrony",
             packages=("chrony",), sudo=True)
    yield op(systemd.service, name="Run chrony", service="chrony",
             running=True, enabled=True, sudo=True)

    # (5) Hardening: a drop-in that tightens sshd, then a reload — the
    #     "handler" is just the next request in the same generator.
    yield op(systemd.dropin, name="Harden sshd",
             filename="10-reemote.conf", unit="sshd.service",
             content="[Service]\nPermitRootLogin=no\n",
             sudo=True)
    yield op(systemd.daemon_reload, name="Reload systemd after drop-in",
             sudo=True)
    yield op(systemd.service, name="Restart sshd", service="sshd",
             restarted=True, sudo=True)

Task (5) is the one that shows off the library shape most. In Ansible the drop-in is a template plus a notify: restart sshd handler, and the handler fires only if the template reported changed. In reemote the "handler" is ordinary Python: run the config deploy, read its report, freeze the set of hosts that actually changed with reemote.handlers.changed_hosts, and feed that set into a second deploy that calls systemd.service("sshd", restarted=True). No notify keyword, no handler-ordering rules to memorise — just the structured result you already have.

What follows: Reemote can manage Ubuntu instead of Ansible

Once configuration management is a library, everything Python already has becomes available to your Ubuntu deploys:

• Deploy from your application. await run(inventory, deploy) inside a FastAPI handler, a Celery task, a Python GitHub Action, or a REPL.
• Compose with real code. Build the inventory from a database query; generate config text from a Pydantic model; share validation between the app and the deploy.
• Test with pytest. Deploy functions are pure generators — assert on the requests they yield without a server in sight.
• Consume structured results. report.entries[i].changed, .reason, .commands are data you can log, chart, feed to a webhook, or gate a rollout on.
• Two-phase execution for free. Every run prepares then applies; dry=True is a real preview against live facts, not a simulation.
• Same code over SSH or Docker. Flip the connector key and the identical deploy runs against an Ubuntu VM or a local container — test the role before you point it at production, or build an image from the same code that configures a host.
• Handlers as ordinary Python. Read the first deploy's report, freeze the changed hosts, feed them into a second deploy. changed_hosts and restart_handler ship for the common case.

You can use reemote instead of Ansible whenever managing Ubuntu is part of a Python program rather than a shell command in a CI job — which, for most teams building products today, is the more natural shape. And on Ubuntu specifically, you keep apt's and systemd's own vocabularies intact rather than flattening them through a lowest-common-denominator module API.

What Reemote is not

• Not a deployment CLI. There is no reemote command; you write the script.
• Not an inventory format. Inventory is a Python list of dicts — load it from JSON, YAML, a database, or write it inline.
• Not a role ecosystem. Reemote ships modules for apt, systemd, apk, openrc, dnf, files, server, git, mysql, postgresql, iptables, firewalld, ufw, selinux, lxd, snap, flatpak, sysctl, gpg, and hardware — but there is no Ansible Galaxy equivalent.
• Not a translation layer between OSes. Python does not make nginx installable by the same name on Ubuntu and Alpine. You still pick the right module for the target — and on Ubuntu that means apt and systemd, which reemote ships as first-class citizens.

Try it

• Documentation and full guide: https://reemote.org/
• Source: https://github.com/kimjarvis/reemote
• PyPI: pip install reemote
• License: EPL-2.0

If you have ever wanted to describe an Ubuntu box's state in the same language as the rest of your stack — with imports, types, tests, and await, and without translating apt's and systemd's vocabularies through YAML — the docker quickstart at the top of this article is the whole onboarding. Give it a minute.

The problem: configuration management on Alpine

Alpine runs the world's containers, a lot of its edge boxes, and every minimal VM someone cared enough to slim down. It is not Debian and not RHEL, and three things make it its own animal:

• apk (Alpine Package Keeper), not apt or dnf.
• OpenRC, not systemd. A service is an /etc/init.d script managed at runtime with rc-service; a runlevel is a directory of symlinks under /etc/runlevels managed with rc-update.
• musl libc and a deliberately minimal userland — a fresh Alpine ships no Python at all.

That last point is where Ansible hurts first. Ansible executes by pushing modules to a Python interpreter on the managed node. Every mainstream distro already has one; Alpine does not. So the very first task of every Alpine playbook is a bootstrap you would never need anywhere else — the one module that does not require Python, raw, sneaking an interpreter onto the box so Ansible can then talk to it:

- name: Install Python 3 on Alpine          # a whole task just to make Ansible work
  ansible.builtin.raw: test -x /usr/bin/python3 || apk add --no-cache python3

Everything after that is a translation layer. community.general.apk for packages. ansible.builtin.service quietly becoming rc-service/rc-update behind your back. lineinfile edits to /etc/apk/repositories. It works — but you are describing a Python program's worth of logic in YAML, for a target you first had to bootstrap into having Python, driven by a CLI whose result is terminal output you scrape with a regex.

That is the gap: there is no serious configuration-management library you can import and point at an Alpine box.

Try it in under a minute (docker connector)

Reemote ships a docker connector that runs your deploy inside a local container, so you need neither a remote host nor an SSH key to see it work. You do need Docker or Podman installed locally — the connector shells out to whichever CLI you name, and there is no default. Three commands:

# 1. install reemote into a fresh venv (Python 3.13+; pip works just as well as uv)
uv venv .venv && source .venv/bin/activate && uv pip install reemote
# 2. save the script below as alpine_demo.py
# 3. run it — starts a throwaway alpine:3.20 container, configures it, cleans up
python alpine_demo.py

# alpine_demo.py
import asyncio
from reemote import apk, format_log, format_plan, op, run

INVENTORY = [{
    "host": "alpine-demo",
    "connection": {
        "connector": "docker",
        "identifier": "alpine:3.20",
        "docker_cmd": "podman",   # or "docker"
    },
}]

def deploy(host):
    # The first thing you always do on a fresh Alpine: install packages.
    yield op(apk.packages,
             name="Install baseline packages",
             packages=("chrony", "curl"),
             no_cache=True)

async def main():
    plans, report, _ = await run(INVENTORY, deploy)
    print("== Plan ==")
    print(format_plan(plans))
    print("== Applied ==")
    if report is not None:
        print(format_log(report))

asyncio.run(main())

The most common first task after dropping onto a fresh Alpine is the one Ansible itself reaches for first: install packages with apk. Verified output:

== Plan ==
alpine-demo: Install baseline packages [changed: 2 package(s) to install]
== Applied ==
alpine-demo: Install baseline packages [changed: 2 package(s) to install]
    $ apk add --no-cache chrony curl

Three things worth noticing, because they are exactly where Alpine + Reemote differ from Alpine + Ansible:

• No Python bootstrap. Reemote talks to a shell over sshd (or docker exec), not to a Python interpreter on the target. The raw: apk add python3 task simply does not exist here. Under the hood that $ apk add ... line ran as podman exec -i <container> sh -c 'apk add --no-cache chrony curl' — the transport wrapping is invisible in the log by design, so the same deploy reads identically over SSH.
• No -y, no sudo. apk never prompts, so reemote never adds a -y flag (unlike apt and dnf). And the container's exec user is already root, so nothing needed escalating. On a real Alpine host — which ships no sudo — you would flag the request doas=True and reemote would run a passwordless doas -n apk add ....
• no_cache=True is an apk-native modifier. It renders --no-cache, the container-idiomatic "don't leave an index behind" flag. Reemote exposes apk's own vocabulary rather than flattening it into a lowest-common-denominator package API.

One honesty note, the same one the throwaway-container workflow always carries: every run reports [changed: ...], even the second time, because the image target starts a fresh alpine:3.20 container on each invocation, so the packages genuinely are absent each time. Point reemote at a stable target — an SSH host, or an existing container ID — and the second run correctly reports [no change: all packages present]. You will see exactly that below.

Why Python has real advantages over Ansible

Ansible chose YAML because it is readable and does not require knowing a programming language. That is a fair trade when your team does not write Python. When it does — and most automation teams today do — the trade costs more than it saves, and on Alpine the bill is higher still:

• The target does not need Python. Ansible's whole execution model assumes an interpreter on the managed node. Reemote assumes a POSIX shell and sshd. On a minimal Alpine that is the difference between a bootstrap task and none.
• Your editor knows your code. apk.packages and openrc.service are functions: go-to-definition, rename, autocomplete, and a type check that catches a typo before it reaches a production box. A misspelled YAML module name surfaces at runtime.
• No Jinja2 as a second language. {{ hostvars[...] }} is a stringly-typed escape hatch that fights your IDE and your tests. In reemote the value is just a Python expression.
• Composition is import, not directory layout. Roles load by convention; reemote deploys are generators you import, call, and loop over.
• The result is data, not stdout. If your application needs to know what changed, you read report.entries[i].changed — you do not regex-scrape a terminal.
• Testing is pytest. A deploy function is a pure generator; you can inspect the requests it yields without touching a server. No molecule, no testinfra, no ansible-lint.

The solution: Reemote is a library

Reemote is a Python package (pip install reemote) with two properties that separate it from every CLI-shaped tool.

Async end to end, on asyncssh

The transport is asyncssh, and the entire execution path — connecting, gathering facts, sending commands, closing — is coroutines. You await a deploy and hosts progress in parallel; network waits overlap across hosts while each host's commands stay in order. Your deploy script remains a plain synchronous generator, so you never write async inside an operation.

plans, report, hosts = await run(inventory, deploy)

run is the single entry point: it validates the inventory, opens connections lazily, plans and applies in two phases, then closes everything in a finally. The same code runs over SSH or over the docker connector — you pick the transport in the inventory entry, not in the deploy. That is why you can develop an Alpine role against a local container and ship it to a VM without changing a line.

A library returning structured results, not a CLI

run(...) returns (plans, report, hosts):

• plans — {host_label: [PlannedOperation, ...]}, the proposed work per host.
• report — an ApplyReport with a LogEntry per applied operation, each carrying changed, reason, and the exact commands sent. None when dry=True.
• hosts — the materialised host objects.

format_plan and format_log (what you saw above) are convenience renderers for humans. Your application consumes the objects directly — no parsing stdout to figure out what happened.

The apk module: Alpine's package manager as Python

apk pairs read-only facts with operations that converge the box toward a described state. An operation reads a fact, decides whether anything must change, and yields commands only when it must — so re-running is a no-op.

Operations

• apk.packages — install, upgrade, or remove by name. A name can be pinned <pkg>=<version>, and a pin counts as present only when that exact version is installed. present=False removes; latest=True upgrades unpinned names; no_cache/no_scripts are the apk-native --no-cache/--no-scripts modifiers. Idempotence reads ApkInstalledPackages.
• apk.repository — ensure one line in /etc/apk/repositories. This is the day-one "enable the community repo" task, done as a spool-and-install rewrite of the file (never an in-place sed -i), so the other lines, comments, and ordering survive verbatim. A path parameter manages a non-standard repositories file.
• apk.virtual — manage an apk virtual package group (apk add -t <tag> ...), the build-dependency pattern a compile step wraps itself in so its toolchain does not linger on the finished image; tear it down with one apk del <tag>.
• apk.hold — pin packages back from upgrades. apk has no apt-mark hold; it holds by writing a version constraint into /etc/apk/world, and that is exactly what this does, with version-aware idempotence.
• apk.autoremove — purge the orphaned packages nothing in world needs any more (apk add --purge). apk has no autoremove verb, so reemote splits the --purge flag into a standalone, separately-plannable step.

Facts — ApkInstalledPackages, ApkExplicitPackages (the world), ApkHeldPackages, ApkAutoremovablePackages, ApkRepositories, ApkRepositoriesFile, and ApkPackage (one package's version, size, dependencies, provides). Every list fact returns sorted, de-duplicated, JSON-printable typed entries — not a scraped string.

The openrc module: Alpine's init as Python

OpenRC manages services along two independent axes: whether a service is running right now (rc-service), and whether it is enabled in a runlevel at boot (rc-update). A service can be enabled but stopped, or running but not enabled. openrc.service handles both in one operation.

Operations

• openrc.service — running=True/False/None compares OpenrcStatus and starts/stops only on a difference; enabled=True/False/None compares OpenrcEnabled for a runlevel (default "default") and yields rc-update add/del only on a difference; restarted=True/reloaded=True are the non-idempotent verbs, each gated on the service actually running.
• openrc.runlevel — the dedicated runlevel-membership verb: assign or unassign a service without touching its runtime state.
• openrc.custom_runlevel — manage the runlevel directories themselves, including stacking (rc-update -s add). Removal unstacks from every target first, then deletes the directory, so no dangling symlink survives.
• openrc.config — set or unset one shell-variable assignment in /etc/rc.conf or /etc/conf.d/<service>, via the same spool-and-install rewrite as apk.repository.

Facts — OpenrcStatus (name → running bool), OpenrcEnabled (name → enabled-in-runlevel bool), OpenrcServices (the raw state word, so a crashed service is distinguishable from a stopped one), OpenrcRunlevels, OpenrcVersion, and OpenrcConfigFile.

One honest boundary: there is no openrc.mask. OpenRC has no masking mechanism (no systemd-style symlink-to-/dev/null), so reemote does not pretend to emulate one — disable the service in every runlevel instead.

Install OpenRC, then use it — self-contained and verified

The classic Alpine post-install move is install the daemon, then enable and start it — chrony for time sync, say. In reemote that is apk.packages followed by openrc.service. There is one wrinkle worth understanding first, because it is the two-phase model showing through:

You cannot install OpenRC and read OpenRC facts in the same deploy. run() gathers facts for every operation during the prepare pass, before the apply pass sends a single command. So a one-deploy apk.packages(("openrc", …)) → openrc.service(…) dies at plan time: openrc.service runs rc-status / rc-update show -v while OpenRC is not installed yet → exit 127 → CommandNotFoundError.

The fix is two run() calls — and the docker connector keeps it fully self-contained: no manual podman run, no custom Dockerfile. Run 1 installs OpenRC into a throwaway alpine:3.20 container; on close the connector commits that container into a new image and hands you its short ID as hosts[0].image_id. Run 2 targets that committed image, so OpenRC already exists when its prepare pass reads the facts:

# alpine_openrc.py
import asyncio
from reemote import apk, format_log, format_plan, openrc, op, run

DOCKER_CMD = "podman"   # or "docker"


def conn(identifier):
    return {"host": "alpine-demo",
            "connection": {"connector": "docker",
                           "identifier": identifier,
                           "docker_cmd": DOCKER_CMD}}


def bootstrap(host):
    # Run 1 -- install OpenRC itself. apk is in the stock image, so this
    # deploy's prepare stage gathers facts fine. On close the docker connector
    # commits the container into a new image, OpenRC baked in.
    yield op(apk.packages, name="Install openrc",
             packages=("openrc",), no_cache=True)


def deploy(host):
    # Run 2 -- targets the committed image, so OpenRC already exists and this
    # prepare stage can read rc-status/rc-update without a CommandNotFoundError.
    yield op(apk.packages, name="Install chrony",
             packages=("chrony",), no_cache=True)
    yield op(openrc.service, name="Enable chronyd at boot",
             service="chronyd", running=None, enabled=True)


async def main():
    # Run 1: bootstrap OpenRC into a throwaway alpine:3.20 container.
    plans, report, hosts = await run([conn("alpine:3.20")], bootstrap)
    print("== Run 1: install OpenRC ==")
    print(format_plan(plans))
    if report is not None:
        print(format_log(report))

    # Chain: run 2 starts from the image run 1 committed.
    image_id = hosts[0].image_id
    print(f"(committed image: {image_id})")
    plans, report, _ = await run([conn(image_id)], deploy)
    print("== Run 2: install chrony + enable chronyd ==")
    print(format_plan(plans))
    if report is not None:
        print(format_log(report))

asyncio.run(main())

Verified output (the committed image ID is ephemeral — yours will differ):

== Run 1: install OpenRC ==
alpine-demo: Install openrc           [changed: 1 package(s) to install]
alpine-demo: Install openrc           [changed: 1 package(s) to install]
    $ apk add --no-cache openrc
(committed image: 37a2428674df)
== Run 2: install chrony + enable chronyd ==
alpine-demo: Install chrony           [changed: 1 package(s) to install]
alpine-demo: Enable chronyd at boot   [changed: service chronyd is not enabled, will enable]
alpine-demo: Install chrony           [changed: 1 package(s) to install]
    $ apk add --no-cache chrony
alpine-demo: Enable chronyd at boot   [changed: service chronyd is not enabled, will enable]
    $ rc-update add chronyd default

Each operation prints twice — once from format_plan (the proposal), once from the format_log apply report (with the $ … commands actually sent). Within run 2 the ordering is the point: the apply phase runs in lockstep, one request index at a time across all hosts, so every host finishes the chrony install before any host begins the service step. openrc.service therefore always sees the /etc/init.d/chronyd script the install just delivered. There is no combined "ensure" operation to maintain — the halves compose, and each is idempotent against its own facts.

A throwaway image target starts fresh every time, so re-running the whole script always reports [changed: …]. Point run 2 at a stable target instead — an SSH host, or an existing container ID — and re-running it converges, which is the [no change: …] the quickstart could not show:

alpine-demo: Install chrony           [no change: all packages present]
alpine-demo: Enable chronyd at boot   [no change: service chronyd is enabled]

Two Alpine-specific honesty notes:

• The stock alpine image ships no OpenRC — rc-service/rc-update are absent until you apk add openrc, which is exactly what run 1 does. On a real Alpine VM or bare-metal box OpenRC is the init system and is always present, so there you skip the bootstrap run and keep only run 2.
• running=True (an actual rc-service chronyd start) needs OpenRC to be PID 1, which a plain docker run ... tail -f /dev/null container is not. That is why this example uses running=None, enabled=True — the boot-assignment half (rc-update) is init-independent and works anywhere. On a real Alpine host, add running=True and reemote will start the daemon too.

On a real host both halves write root-owned state, so flag them doas=True: Alpine has no sudo, and reemote runs doas -n, which needs a permit nopass rule for your login user in /etc/doas.conf.

A day-one Alpine playbook, in Python

Here is the routine post-install set — the tasks an Alpine playbook always opens with — as one reemote deploy. No Python bootstrap, no YAML, no Jinja2:

def deploy(host):
    # (1) There is no "install Python so the tool works" step: reemote needs
    #     only a shell + sshd on the target.

    # (2) Enable the community repository (spool-and-install rewrite of the file).
    yield op(apk.repository, name="Enable community repo",
             src="http://dl-cdn.alpinelinux.org/alpine/v3.20/community",
             doas=True)

    # (3) Time sync: install chrony, then enable and start chronyd.
    yield op(apk.packages, name="Install chrony",
             packages=("chrony",), doas=True)
    yield op(openrc.service, name="Run chronyd", service="chronyd",
             running=True, enabled=True, doas=True)

    # (5) Baseline daemons every Alpine box wants up and enabled.
    for svc in ("crond", "networking"):
        yield op(openrc.service, name=f"Ensure {svc}", service=svc,
                 running=True, enabled=True, doas=True)

    # (6) Resolvers: a plain content install, mode enforced.
    yield op(files.install, name="Write resolv.conf",
             content="nameserver 1.1.1.1\nnameserver 8.8.8.8\n",
             dest="/etc/resolv.conf", mode="0644", doas=True)

Task (4), hardening sshd_config, is the one that shows off the library shape most. In Ansible it is a lineinfile plus a notify: restart sshd handler. In reemote it is files.edit (or files.transform) rewriting the PermitRootLogin line, and the "handler" is ordinary Python: run the config deploy, read its report, freeze the set of hosts that actually changed with reemote.handlers.changed_hosts, and feed that set into a second deploy that calls openrc.service("sshd", restarted=True). No notify keyword, no handler-ordering rules to memorise — just the structured result you already have.

What follows: Reemote can manage Alpine instead of Ansible

Once configuration management is a library, everything Python already has becomes available to your Alpine deploys:

• Deploy from your application. await run(inventory, deploy) inside a FastAPI handler, a Celery task, a Python GitHub Action, or a REPL.
• Compose with real code. Build the inventory from a database query; generate config text from a Pydantic model; share validation between the app and the deploy.
• Test with pytest. Deploy functions are pure generators — assert on the requests they yield without a server in sight.
• Consume structured results. report.entries[i].changed, .reason, .commands are data you can log, chart, feed to a webhook, or gate a rollout on.
• Two-phase execution for free. Every run prepares then applies; dry=True is a real preview against live facts, not a simulation.
• Same code over SSH or Docker. Flip the connector key and the identical deploy runs against an Alpine VM or a local container — test the role before you point it at production, or build an image from the same code that configures a host.
• Handlers as ordinary Python. Read the first deploy's report, freeze the changed hosts, feed them into a second deploy. changed_hosts and restart_handler ship for the common case.

You can use reemote instead of Ansible whenever managing Alpine is part of a Python program rather than a shell command in a CI job — which, for most teams building products today, is the more natural shape. And on Alpine specifically, you drop the Python-bootstrap task entirely.

What Reemote is not

• Not a deployment CLI. There is no reemote command; you write the script.
• Not an inventory format. Inventory is a Python list of dicts — load it from JSON, YAML, a database, or write it inline.
• Not a role ecosystem. Reemote ships modules for apk, openrc, apt, dnf, files, systemd, server, git, mysql, postgresql, iptables, firewalld, ufw, selinux, lxd, snap, flatpak, sysctl, gpg, and hardware — but there is no Ansible Galaxy equivalent.
• Not a translation layer between OSes. Python does not make nginx installable by the same name on Alpine and Debian. You still pick the right module for the target — and on Alpine that means apk and openrc, which reemote ships as first-class citizens.

Try it

• Documentation and full guide: https://reemote.org/
• Source: https://github.com/kimjarvis/reemote
• PyPI: pip install reemote
• License: EPL-2.0

If you have ever wanted to describe an Alpine box's state in the same language as the rest of your stack — with imports, types, tests, and await, and without bootstrapping Python onto the target just to configure it — the docker quickstart at the top of this article is the whole onboarding. Give it a minute.

The problem

Python is the language of automation glue: CI, dashboards, data pipelines, deploy orchestration. But the moment you want to describe the state of a server, you leave Python behind. You write YAML for Ansible. You write Ruby for Chef. You write Puppet DSL for Puppet. Then you invoke a binary that parses, plans, and executes for you.

There is no serious configuration-management library for Python. Nothing you can import. Nothing that returns typed results you can inspect. Nothing you can embed inside an application, unit-test with pytest, or await from an async handler. The mainstream tools are all command-line binaries wrapped around their own task language, and if you want to trigger a deploy from Python, you end up shelling out to that binary and scraping its terminal output.

That is the gap.

Try it in under a minute (docker connector)

Reemote ships a docker connector that runs your deploy inside a local container, so you do not need a remote host or an SSH key to see it work. You do need Docker or Podman installed locally — the connector shells out to whichever CLI you name in the inventory, and there is no default. Three commands:

# 1. Install (Python 3.13+; pip works just as well as uv)
uv venv .venv && source .venv/bin/activate && uv pip install reemote

# 2. Save the script below as hello.py, then run it
python hello.py

# hello.py
import asyncio
from reemote import files, format_log, format_plan, op, run

INVENTORY = [{
    "host": "demo",
    "connection": {
        "connector": "docker",
        "identifier": "alpine:3.20",
        "docker_cmd": "podman",   # or "docker"
    },
}]

def deploy(host):
    yield op(files.install,
             name="Write a greeting",
             content="Hello from reemote!\n",
             dest="/tmp/reemote-hello.txt",
             mode="0644")

async def main():
    plans, report, _ = await run(INVENTORY, deploy)
    print("== Plan ==")
    print(format_plan(plans))
    print("== Applied ==")
    if report is not None:
        print(format_log(report))

asyncio.run(main())

Reemote starts a throwaway alpine:3.20 container, writes the file inside it, prints the plan and the apply log, then commits the container into a new image and removes it. Verified output:

== Plan ==
demo: Write a greeting         [changed: content /tmp/reemote-hello.txt is absent, will install]
== Applied ==
demo: Write a greeting         [changed: content /tmp/reemote-hello.txt is absent, will install]
    $ scp <files install> -> /tmp/reemote-install-2e52d4f8373a608a/content
    $ sh -c 'mkdir -p /tmp && cp /tmp/reemote-install-2e52d4f8373a608a/content /tmp/reemote-hello.txt && chmod 644 /tmp/reemote-hello.txt && rm -rf /tmp/reemote-install-2e52d4f8373a608a'

Two things worth noticing:

• The $ scp and $ sh -c lines are command descriptors rendered canonically — they look the same whether the transport is SSH, docker, or podman. Under the hood reemote is running podman cp and podman exec -i demo sh -c '...'; the transport wrapping is invisible in the log by design, so the same deploy reads the same on any target.
• Every run reports [changed: ... is absent, will install], even the second time. That is not a bug — the image workflow starts a fresh throwaway container from alpine:3.20 on every invocation, so the file genuinely is absent each time. Point reemote at a stable target (an SSH host, or an existing container ID) and the second run correctly reports [no change: content already up to date]. Idempotence is a property of the operations against a persistent state, and the quickstart deliberately trades persistence for a zero-setup demo.

That is the whole loop. Describe the state you want, hand over an inventory, await the result. No CLI, no playbook, no YAML.

Why Python has real advantages over Ansible

Ansible chose YAML because it is readable and it does not require knowing a programming language. That is a fair trade-off when your team does not write Python. When your team does — and most automation teams today do — the trade-off costs you more than it saves:

• Your editor does not know your YAML. No go-to-definition, no rename, no reliable type check. A typo in a module name surfaces at runtime, in production.
• Jinja2 is a second language inside the first. {{ hostvars[...] }} is a stringly-typed escape hatch that fights your IDE and your test suite.
• Roles load by convention, not by import. Composition becomes a directory-layout puzzle rather than a from ... import ....
• The result is terminal output. If your application needs to know what changed, you parse stdout with a regex and hope.
• Testing means testinfra, molecule, ansible-lint. Not pytest. You cannot import a task and inspect it.

Python already solves all of these. import gives you composition. Types give you editor support. pytest gives you tests. await gives you concurrency. Data structures give you results you can consume programmatically. The reason configuration management did not use Python is that nobody shipped the library.

The solution: Reemote is a library

Reemote is a Python package (pip install reemote) with two properties that separate it from every CLI-shaped tool:

Async end to end, on asyncssh

The transport is asyncssh, and the entire execution path — connecting, gathering facts, sending commands, closing — is coroutines. You await a deploy and hosts progress in parallel. Within a deploy, hosts step through operations in lockstep; commands for one host run in order; network waits overlap across hosts. Your deploy script stays a plain synchronous generator, so you never write async inside an operation.

plans, report, hosts = await run(inventory, deploy)

run is the single entry point. It validates the inventory, opens connections lazily, plans and applies in two phases, then closes everything in a finally. Same code over SSH or over the docker connector — pick the transport in the inventory entry, not in the deploy.

A library returning structured results, not a CLI

run(...) returns (plans, report, hosts):

• plans — {host_label: [PlannedOperation, ...]}, the proposed work per host.
• report — an ApplyReport with a LogEntry per applied operation, each carrying changed, reason, and the exact commands that were sent. None when dry=True.
• hosts — the materialised host objects.

No parsing stdout to figure out what happened. You already have the objects. format_plan and format_log are convenience renderers for humans; your application consumes the data directly.

Four words to know

• Inventory — a list of dicts naming your targets and how to reach them.
• Fact — a read of remote state (hostname, installed packages, file contents).
• Operation — a request to converge the server toward a described state. Operations read facts, decide whether anything must change, and yield commands only when it must.
• Action — an immediate, non-deploy escape hatch (Shell, Script, WaitForConnection) for one-off commands.

A deploy is a generator that yields operation requests in order:

def deploy(host):
    yield op(apt.packages, name="Install nginx",
             packages=("nginx",), sudo=True)
    yield op(files.install, name="Write landing page",
             content=PAGE, dest="/var/www/html/index.html",
             mode="0644", sudo=True)
    yield op(systemd.service, name="Run nginx",
             service="nginx", running=True, enabled=True, sudo=True)

Every request argument is hashable, every deploy is a pure function of its host, and the runner executes it twice — once to plan, once to apply — with a determinism guard that raises if the two passes disagree. dry=True stops after the plan and gives you a real preview against live facts.

What follows: Reemote can replace Ansible

Once configuration management is a library, everything Python already has becomes available to your deploys:

• Deploy from your application. await run(inventory, deploy) inside a FastAPI handler, a Celery task, a GitHub Action written in Python, or a REPL.
• Compose with real code. Build the inventory from a database query. Generate config text from a Pydantic model. Share validation logic between the app and the deploy.
• Test with pytest. Deploy functions are pure generators — inspect the requests they yield without touching a server.
• Consume structured results. report.entries[i].changed, .reason, .commands are data you can log, chart, feed to a webhook, or gate a rollout on.
• Two-phase execution for free. Every run prepares then applies. dry=True is a real preview against live state, not a simulation.
• Same code over SSH or Docker. Flip the connector key and the identical deploy runs against a remote server or a local container — useful for testing a role before you point it at production, or for building an image from the same code that configures a host.
• Handlers as ordinary Python. No notify/handler keyword. Read the first deploy's report, freeze the hosts that changed, feed that set into a second deploy. reemote.handlers.changed_hosts and restart_handler ship as helpers for the common case.

You can use Reemote instead of Ansible whenever deployment is part of a Python program rather than a shell command in a CI job — which, for most teams building products today, is the more natural shape.

What Reemote is not

It is worth naming the boundaries:

• Not a deployment tool. There is no reemote command. You write the script.
• Not an inventory format. Inventory is a Python list of dicts. Load it from JSON, YAML, a database, or write it inline.
• Not a role ecosystem. Reemote ships modules for apt, dnf, apk, files, systemd, server, git, mysql, postgresql, iptables, firewalld, ufw, selinux, lxd, snap, flatpak, sysctl, gpg, openrc, and hardware — but there is no Ansible Galaxy equivalent.
• Not a translation layer between OSes. Python does not make nginx installable by the same name on Alpine and Debian. You still pick the right module for the target.

What it is, is the missing library.

Try it

• Documentation and full guide: https://reemote.org/
• Source: https://github.com/kimjarvis/reemote
• PyPI: pip install reemote
• License: EPL-2.0

If you have ever wanted to describe server state in the same language as the rest of your stack — with imports, types, tests, and await — the docker quickstart at the top of this article is the whole onboarding. Give it a minute.