Self-healing deployment agent

Your deploy failed once. It should never cost you an afternoon again.

NoMeshOps deploys your project on a machine, and when the deploy breaks it fixes it: a rules table first, then a knowledge base of fixes it has already proven, and a model only for errors nobody has seen yet. Every fix has to survive a real health check before it is remembered.

Watch it fix a deploy

Hosted on our cloud, driven from your terminal. Also runs on your own machines over AWS Systems Manager, or locally in Docker.

nomeshops deploy — recorded run

The problem

The same five errors, solved over and over, by everyone

Deployment failures are rarely novel. They are the same handful of environment mismatches, and the fix is usually one line. What costs the afternoon is finding that line again: reading the traceback, searching, trying three suggestions, discovering the box has a different Python than your laptop. Then a teammate hits the identical error next week and starts from zero, because the answer lived in someone's head.

Error: pg_config executable not found

A database driver is compiling from source and the machine has no Postgres headers. One package install fixes it. Nothing on screen says which package.

No matching distribution found for reqests

A typo in a requirements file. Obvious once you see it, invisible while you are scanning a hundred lines of pip output.

ensurepip is not available

A fresh cloud image without pip or venv. Nothing is broken; the machine was simply never prepared.

Successfully installed — then the app never answers

The worst one. Install exits zero, CI goes green, and the service is dead on arrival because an import fails at startup.

Who this is for

Anyone who deploys to machines they do not control the image of

Solo builders shipping to a VPS

You have no platform team. Every environment error is yours to solve, at night, from a phone screenshot of a traceback.

Small teams without an internal platform

The fixes live in Slack threads and one person's memory. When that person is on leave, the knowledge is gone.

Teams running mixed fleets

Ubuntu and Amazon Linux, x86 and Graviton, three Python versions. The same project fails differently on each box.

Students and hackathon teams

You are deploying an unfamiliar stack on a deadline, and an hour lost to a missing header is an hour not spent building.

How it works

Cheap answers first, the model last

Most failures do not need intelligence, they need someone who has seen them before. So the agent walks a ladder and stops at the first rung that works. The colours below are the ones the terminal actually prints.

Rung 1 · deterministic

Rules it can prove

It fingerprints the machine, compares that against what your project declares, and names the mismatches before touching the network. No guessing and no model call.

0.18 ms average

Rung 2 · remembered

Fixes it has already proven

Each failure gets a signature built from the error, the package, the operating system, the architecture and the Python version. If that signature has a verified fix, it is applied straight away.

1 ms local · 301 ms on AWS

Rung 3 · generated

A model, only for the genuinely new

Only when the first two rungs miss does it ask Claude for one structured fix, under a strict execution contract. One model-assisted retry per run, never a loop.

2.3 s, once per new error

A fix is not a fix until the app answers

Nothing is remembered on the strength of an exit code. A fix has to carry the deploy through the whole chain below, including the last link, which is the one most tools skip: proving that the process answering the health check is the one the agent just started, and not something left running on that port.

dependencies install every package imports process starts health endpoint returns 200 responder is our process

Failures that are not your project's fault are handled separately and never learned from. A network timeout gets a plain retry, not a fix, because a knowledge base that learns from coincidence gets worse over time rather than better.

Measured, not claimed

What it did on real machines

Two EC2 instances, same operating system and Python version, same broken project. The only difference is that the second run happened after the first one taught it something.

Run	Path taken	Model calls	Time
First machine, unknown error	rules miss, memory miss, model proposes a fix, verified, stored	1	42 s
Second machine, same error	memory hit in 301 ms, same fix, verified	0	34 s
Different OS, Python 3.9	rules predicted the missing tooling and installed it first	0	58 s
Unrelated project, same error	memory hit in 1 ms, fix transferred across projects	0	24 s

Measured September 2026 in ap-south-1 and in local Docker. The agent also passes 11 of 11 end-to-end scenarios, including deliberate failures: an app that crashes at startup, a wrong health path, a bad repository URL and an unreachable target. Each of those must fail cleanly and teach it nothing.

Ready when you are

Use NoMeshOps

It is a terminal tool. Sign in once from your shell, the way you would with aws login, and deploy from there. Or run the open-source version on your own machines.

Docs

Running it from your terminal

Two modes. Local mode needs only Docker and is the fastest way to see the whole loop. AWS mode drives real EC2 instances over Systems Manager.

1. Install

Python 3.11 or newer. Clone the repository and create a virtual environment.

git clone https://github.com/SibgathKhan777/NoMeshOps.git
cd NoMeshOps
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt

2. Local mode — no AWS account

Two Docker containers stand in for servers. One is a bare Ubuntu image with no Python and no git, so you can watch the rules table prepare it.

# point every backend at your laptop
cp .env.local.example .env

# start the practice targets
./scripts/local_targets.sh

# deploy a project onto one of them
.venv/bin/python -m cli.demo deploy \
  --repo https://github.com/SibgathKhan777/nomeshops-sample.git \
  --instance nomeshops-ubuntu22

# run it a second time: the fix is now remembered
.venv/bin/python -m cli.demo deploy \
  --repo https://github.com/SibgathKhan777/nomeshops-sample.git \
  --instance nomeshops-al2023

# clean up
./scripts/local_targets.sh --stop

3. AWS mode — your own instances

Targets need the Systems Manager managed-instance policy and the tag nomeshops=target. The provisioning script creates the fix table and the log bucket for you.

export AWS_PROFILE=default AWS_REGION=ap-south-1

# DynamoDB table for fixes, S3 bucket for audit logs
./scripts/provision.sh

# three practice instances: Ubuntu, Amazon Linux, Graviton
./scripts/launch_targets.sh

# deploy against a real instance id
.venv/bin/python -m cli.demo deploy \
  --repo https://github.com/you/your-api.git \
  --instance i-0123456789abcdef0

# when you are done, remove every tagged instance
./scripts/launch_targets.sh --terminate

4. Useful flags

The agent guesses a start command from your manifest. Override it when your entry point is unusual.

--start-command	How to start your app, if it is not `app:app` on uvicorn
--port	Port the app listens on. Default 8000
--health-path	Path polled to confirm the app is alive. Default `/health`
--branch	Branch or tag to deploy
--keep-running	Leave the app running after a verified deploy
--url	Drive a deployed orchestrator instead of running the loop locally

5. Inspecting what it learned

Everything it remembers and every attempt it made are readable from the same terminal.

# every verified fix, with how many times it has held up
.venv/bin/python -m cli.demo fixes list

# the audit record of each attempt
.venv/bin/python -m cli.demo attempts

# what a machine actually looks like, without deploying
.venv/bin/python -m cli.demo fingerprint --instance nomeshops-ubuntu22

6. Your app only has to do one thing

Answer a health endpoint. That is the entire contract, and it is how the agent tells a real deploy from a green exit code.

# app.py
from fastapi import FastAPI
app = FastAPI()

@app.get("/health")
def health():
    return {"ok": True}

Server status: checking…