DEV Community: Marco Montanari

stairway: from a chat idea to a running Claude Code experiment on my own server

Marco Montanari — Mon, 12 Oct 2026 12:37:09 +0000

Most of my side projects start the same way: I'm on my phone, talking an idea through with Claude, and at
some point the conversation is good enough that I want to try it. Then the momentum dies. I have to get to
a laptop, SSH into my server, make a folder, start Claude Code, and paste in a summary of everything we just
discussed.

So I built stairway: a small MCP server that lets the chat do that
step itself.

"Ok, let's try it. Create an experiment called rss-digest and brief it with what we said."

A few seconds later there's a folder on my server, a git repo in it, and a Claude Code session already working
on the brief. The session shows up in claude.ai/code, so I can follow it from my phone.

What it does

stairway is one Python file, standard library only (Python 3.8+), about 1,700 lines. It exposes these MCP
tools:

create_experiment(name, prompt) creates <root>/<name>, runs git init, and starts claude --remote-control <name> "<prompt>" inside a detached screen.
send_prompt(name, prompt) passes more instructions to that running session, mid-conversation.
attach_folder(path) lets Claude use an existing project, but only after I press Approve on stairway's status page.
experiment_status, open_editor, stop_experiment, forget_experiment and friends.

Around those tools there are three ways to work on an experiment:

claude.ai/code, because every session runs with remote control on.
A browser VS Code, started on demand per experiment and proxied by stairway. The first terminal joins the Claude session, and every other terminal is a normal shell in the folder.
A Telegram group. Add the bot, approve the group, /new picnic-planner <brief>, and from then on you talk to Claude by mentioning the bot, while the humans discuss what it builds. Its replies, permission requests and files come back to the group.

The parts I found interesting

An OAuth 2.1 server with no storage

My first version used a token in the URL. claude.ai reached the server and got a valid initialize
response… and then went looking for OAuth anyway (/.well-known/oauth-protected-resource, dynamic client
registration at /register), and gave up when those returned 404.

So stairway is its own small OAuth 2.1 authorization server: discovery documents, dynamic client
registration, PKCE (S256), refresh tokens. The twist is that nothing is stored. Client IDs, access tokens
and refresh tokens are all HMAC-signed blobs:

def _sign(payload):
    body = _b64(json.dumps(payload, separators=(",", ":")).encode())
    return body + "." + _b64(hmac.new(TOKEN.encode(), b"oauth." + body.encode(), hashlib.sha256).digest())

A registered client is just {"k": "client", "r": [redirect_uris], "n": name}, signed. Only the short-lived
authorization codes live in memory. As a bonus, rotating the one server secret revokes every grant at once.

Typing into a TUI, reliably

claude --remote-control gives you an interactive session that's also visible on claude.ai. To pass it more
prompts, stairway types into the screen it runs in. A naive screen -X stuff "text\r" breaks on multi-line
prompts, since each newline submits. It also mangles ^ and \.

The fix is a bracketed paste: load the text into screen's paste buffer from a file, wrapped in
ESC[200~ … ESC[201~, paste it, then press Enter.

f.write("\033[200~" + prompt + "\033[201~")
subprocess.run(["screen", "-S", session, "-X", "readbuf", "-e", "utf8", path])
subprocess.run(["screen", "-S", session, "-X", "paste", "."])
_stuff(session, "\r")

Claude Code sees it as one paste, multi-line and with every character intact, and queues it if it's busy.

Getting answers out: Claude Code hooks

For Telegram I needed Claude's replies, and scraping a TUI is miserable. Claude Code's hooks solve this. The
Stop hook payload includes last_assistant_message, so each session starts with:

{"hooks": {
  "Stop":         [{"hooks": [{"type": "command", "command": "curl -s --data-binary @- 'http://127.0.0.1:8765/hooks/<name>/stop?k=<key>'"}]}],
  "Notification": [{"hooks": [{"type": "command", "command": "curl -s --data-binary @- '…/notify?k=<key>'"}]}]
}}

stairway relays the reply to the bound Telegram group, as a reply to the message that asked. Permission
prompts arrive as "⏳ needs your permission", which the group can answer with /approve or /deny. An
--append-system-prompt tells Claude which curl sends a file it made to the group, so charts and images
just show up there.

The red bars

Inside screen, Claude Code's UI was covered in solid red bars. Capturing the raw output showed why: Claude
draws with 24-bit colors (ESC[38;2;153;153;153m), and screen 4.x doesn't understand them. It reads 38,
2, 153, … as separate attributes, and some of those numbers mean "red background". Setting
COLORTERM or FORCE_COLOR didn't help. Starting the session with Claude Code's ANSI theme did:

--settings '{"theme": "dark-ansi"}'

It's set per process, so my own Claude Code theme stays as it is.

A browser VS Code without dependencies

code-server listens on a unix socket per experiment, and stairway proxies /code/<name>/ to it with a
deliberately dumb byte pipe. It forwards the request head, then shovels bytes both ways with select() until
either side closes. Websockets just work, and plain requests get Connection: close so a keep-alive
connection never gets mixed up between routes.

Security, honestly

stairway's purpose is to let an AI agent run commands on your machine when asked. So:

one strong secret, OAuth with your explicit consent, and HTTPS in front
existing folders and Telegram groups do nothing until you approve them on the status page
choose each experiment's Claude Code permission_mode deliberately; default asks before acting
run it as a dedicated user, ideally on a box you're happy to give an agent

The repo has a security doc with the full
threat model.

Try it

git clone https://github.com/sirmmo/stairway.git && cd stairway
cp .env.example .env   # set STAIRWAY_TOKEN, STAIRWAY_PUBLIC_URL, ...
set -a; . ./.env; set +a; python3 stairway.py

Put it behind HTTPS and add https://<host>/mcp as a custom connector in claude.ai. Then ask Claude to
create your first experiment. You'll need Claude Code logged in with a claude.ai subscription on the server,
because remote control requires it. GNU screen is required, and code-server and a Telegram bot token are
optional.

I built it in a morning of pair-programming with Claude Code, which was a fitting way to make a tool for
starting Claude Code sessions. It's MIT licensed. Issues and PRs are welcome:
github.com/sirmmo/stairway.

What would you want your chat to be able to spin up?

Markette: an open-source, self-hosted tool to write once and publish everywhere

Marco Montanari — Sun, 11 Oct 2026 07:27:21 +0000

I publish to a lot of places: Bluesky, Mastodon, X, LinkedIn, a couple of Telegram channels, a blog. I also help a few organizations that do the same, each with its own accounts and its own people. The existing tools were either SaaS with per-channel pricing, or self-hosted but limited to a handful of networks with a scheduler that was little more than a cron job.

So I built Markette: write a post once, adapt it for each network, schedule it at the right moment, and see what worked. It is open source (AGPL-3.0) and you can run it on your own server with one docker compose up.

This article is a tour of what it does and how it is built.

What it publishes to

24 destinations, behind a single provider contract:

Social: X, Bluesky, Threads, Mastodon (any instance), LinkedIn (people and company pages), Facebook Pages, Instagram, YouTube, Reddit
Messaging: Telegram, Slack, Discord, WhatsApp, WeChat, QQ
Blogs and sites: WordPress, Drupal, Ghost, Medium, DEV (and any Forem community), Hugo (it commits a page bundle to your git repo)
Newsletters: Brevo and Listmonk, where each post becomes an email campaign
Anything else: a signed JSON webhook, for n8n, Make, Zapier or your own code

Yes, this article was written in Markette and published through its DEV integration.

Write once, tailor per channel

A post fans out into one target per channel. Every target can override the text, media and options: a short version for X, a longer one with a first comment for LinkedIn, a title and tags for the blog. Character counters count the way each network does (X weighs links as 23 characters, Bluesky counts graphemes), and every target is validated against its network's rules before anything is scheduled.

A scheduler you can trust

Scheduling is the part I cared about most. Each target gets its own time, chosen by one of these modes:

now or an exact time
queue: the next free weekly slot
best time: the best-scoring free hour for that channel, keeping a minimum gap from other posts

A Celery beat process ticks every 15 seconds and claims due targets with SELECT … FOR UPDATE SKIP LOCKED, so several workers never publish the same thing twice. Errors are classified as retryable (rate limits, 5xx, network: exponential back-off, honouring Retry-After), auth (the channel is flagged for reconnection) or permanent. A worker that dies mid-publish leaves the target as "failed, check before retrying" instead of retrying blindly and risking a duplicate post.

Best time to post, from your own data

The best-time engine keeps a 7×24 grid (weekday × hour) of scores for every channel. It starts from a per-platform prior, so a new channel gets sensible defaults, then blends in the engagement rate of your own posts from the last 180 days. The more posts land in an hour, the more your data wins over the prior. The UI tells you whether a grid comes from defaults, a blend, or your data alone.

Metrics are pulled 1 h, 6 h, 24 h, 3 d, 7 d and 30 d after publishing, plus a daily audience count.

Optional AI, with any provider

AI is optional and goes through OpenRouter or any OpenAI-compatible API (OpenAI, Azure, vLLM, Ollama…). It can suggest times (checked against the engine and the calendar), plan a campaign over a period, and rewrite one text for each network's length and tone. Every call is logged with its tokens and cost, and organizations can have monthly limits.

Built for teams and agencies

Organizations contain workspaces, one per brand or client, with roles from owner to viewer
Channels belong to the organization and can be shared across workspaces
Teams can restrict channels and require approval before posts are scheduled
Single sign-on with any OpenID Connect provider, per organization
Optional Stripe billing if you host it for others

More ways in

MCP server: connect Claude, or any MCP client, and ask it to draft, validate and schedule posts. Every call runs as you, with your roles.
Chrome extension: share the page, a selection, a link or an image straight to the composer.
Android and iOS apps, with a share sheet.
A documented REST API with personal tokens.

The stack

Backend: Django 6 + Django REST Framework, Celery, PostgreSQL, Redis
Frontend: Angular 21, served by nginx or GitHub Pages
Mobile: Capacitor
Channel credentials are encrypted at rest (Fernet), and secrets are write-only in the API

Try it

git clone https://github.com/markette-org/markette-deploy.git
cd markette-deploy && cp .env.example .env   # set the keys and your domain
docker compose up -d
docker compose exec api python manage.py createsuperuser

The self-hosting guide explains where to find the keys for every network.

Website: markette.org
Code: github.com/markette-org

Issues, pull requests and new providers are very welcome. I'd love to hear which network you'd want next, and how you handle publishing to many places today.

pg_i18n: translatable columns in PostgreSQL without rewriting your app

Marco Montanari — Thu, 24 Sep 2026 09:53:43 +0000

Every project I have worked on eventually needed a second language for some text stored in the database. Product names, category labels, descriptions, menu entries. And every time, the same thing happened: the schema was already there, the API was already reading and writing those columns as plain strings, and nobody wanted to touch either.

So the pragmatic hack appeared: someone started writing JSON into the text column.

name
-----------------------------------
Chair
{"en": "Chair", "it": "Sedia"}

Half the rows plain strings, half of them JSON objects, and the application still treating everything as a string. It works until someone asks for a proper list of Italian product names.

I wrote pg_i18n to make this state of affairs a feature instead of a bug. It is pure SQL and PL/pgSQL, no compiled code, and it installs either as a PostgreSQL extension or as a script you load with psql. It works on PostgreSQL 9.5 and up, tested on 14, 16 and 17.

Reading and writing one language

The core is two functions that understand both shapes of the column:

SET i18n.lang = 'it';

SELECT i18n_get(name) FROM products;
-- 'Chair'                       -> Chair     (plain string, returned as-is)
-- {"en":"Chair","it":"Sedia"}   -> Sedia

UPDATE products SET name = i18n_set(name, 'Sedia rossa') WHERE id = 1;
-- 'Chair' -> {"en": "Chair", "it": "Sedia rossa"}

A plain string is taken to be in the default language, so writing Italian to it promotes it to a JSON object instead of losing the English. Reading falls back as far as you want: requested language, then default language, then whatever exists. Or not at all, if you set i18n.fallback = 'none' and want a NULL or an empty string for a language that is not there.

Everything exists for both text and jsonb columns, and the explicit forms are IMMUTABLE, so they go into expression indexes:

CREATE INDEX ON products USING gin (i18n_get(name, 'it', 'en') gin_trgm_ops);
SELECT * FROM products WHERE i18n_get(name, 'it', 'en') ILIKE '%sedia%';

The part I actually needed: the app does not change

The API reads and writes plain strings and it is not going to be rewritten this quarter. Fine. Rename the table and put a view in its place:

ALTER TABLE products RENAME TO products_i18n;
SELECT i18n_wrap_table('products_i18n', '{name,description}', 'products');

The view exposes name and description as plain strings in the session language. INSTEAD OF triggers write back into the JSON, touching only the current language. The application keeps running its old queries against products. The only thing it needs is the language, and that can be set per connection, per transaction, or once per database role:

ALTER ROLE api_it SET i18n.lang = 'it';

Inserts store {"it": "..."}, updates change only Italian and leave the other languages alone, RETURNING gives back the translated row, defaults on omitted columns still apply. I was surprised how little the application notices.

Cleaning up: migrating to jsonb

Once every writer goes through the functions or the view, the text columns can become real jsonb with a constraint:

SELECT * FROM i18n_migration_report('products_i18n', 'name');
--  col_type | total | nulls | plain | translated | other_json
--  text     | 12040 |    15 |  9871 |       2154 |          0

SELECT i18n_migrate_table('products_i18n', '{name,description}', 'en');

Plain strings become {"en": "..."}, the column type changes, and a CHECK makes sure only translation objects get in from now on. The same queries keep working because PostgreSQL picks the jsonb overloads by column type.

Filling the gaps automatically

This is where it got fun. With the languages in the row, "which rows are missing German" is a cheap question, and answering it with a machine translation is a good first draft for product names and labels.

PostgreSQL cannot call HTTP APIs portably, so the split is: the database detects rows missing a configured language and puts them on a queue table, a small Python worker outside the database calls the provider and writes back.

SELECT i18n_auto_enable('products_i18n', 'name', '{en,it,de}',
                        NULL, 'deepl', 'furniture product names, keep brand names untranslated');
SELECT i18n_backfill('products_i18n', 'name');

PG_I18N_PROVIDER=deepl DEEPL_API_KEY=... ./pg_i18n_worker.py

Providers are DeepL, Google Cloud Translation, and OpenRouter, which means any LLM with a prompt that includes the per-column hint above. The rules that keep it safe:

only missing languages are requested, and only what is still missing at write-back time is written. A human translation entered while a job is in flight wins;
a changed source text does not retranslate existing languages;
claims use FOR UPDATE SKIP LOCKED, so you can run several workers;
two views, i18n_coverage and i18n_missing_translations, show what is done and what is still open.

Detecting the language of what was inserted

One more real-world problem: the API knows nothing about languages, so a plain string is assumed to be English, and someone in an Italian session pastes an English text that lands under it. With detection enabled on a column, the worker asks the provider what language the text actually is. If it disagrees with the key the text was stored under, the text moves to the right key and the other languages are filled from it. A language outside your configured set stays under its own key:

inserted, {en,it} configured:  'Bonjour'
after the worker:              {"en": "Hello", "fr": "Bonjour", "it": "Ciao"}

Where it fits, and where it does not

It fits when translations belong inside the row and the application is not going to change: legacy databases with mixed content, string-only APIs, catalogues, CMS labels, multi-tenant apps where each role has its own language.

It does not fit long documents that need per-language versioning and an approval workflow. There a translations table or a translation management system is the better tool.

Try it

git clone https://github.com/sirmmo/pg_i18n
cd pg_i18n && make install
psql -d mydb -c 'CREATE EXTENSION pg_i18n'

Or psql -d mydb -f i18n.sql -f i18n_auto.sql on a managed database where you cannot install extensions. The test suite runs against throwaway Docker containers, including an end-to-end run of the worker with an offline provider.

Docs: https://ingmmo.com/pg_i18n/ · Source: https://github.com/sirmmo/pg_i18n · MIT.

I would like to hear how other people have handled the "JSON in a text column" situation, and which provider you would want next.