explainx / blog
A VPS + tmux setup for autonomous blog publishing solves a problem most teams don't have. Here's why Claude Code on the web, GitHub, and Railway's auto-deploy already cover it — plus the one CI gap worth closing.
Jun 17, 2026
Matt Shumer's viral X thread (109K views, June 2026) surfaced four real ways to control Claude Code from your phone. Here is every method ranked by setup effort, with step-by-step instructions and security guidance for agentic sessions that run with dangerous permissions.
Jul 16, 2026
Anthropic's ClaudeDevs account announced artifact MCP connectors: build a dashboard once, and each viewer pulls live data through their own connectors. explainx.ai explains viewer-scoped auth, plan limits, admin toggles, and how this extends Thariq's thick-artifacts framework.
Jul 16, 2026
Pieter Levels stopped coding locally — Claude Code lives on a VPS, Termius on iPhone and MacBook Pro reach it over SSH, and a MacinCloud Mac Mini runs Xcode for the Nomads iOS app. explainx.ai maps the architecture, when it makes sense, and how to harden credentials after Codex $HOME deletion week.
A tweet makes the rounds every few months: someone's running an autonomous coding agent on a VPS with tmux, SSH-ing in from their phone to check on it, levels.io-style. It's a real pattern for a real problem — a laptop that has to stay open for an agent to keep working.
But the problem doesn't automatically apply to you. If your app already deploys through Railway or Vercel with auto-deploy on push to main, Railway is already your server. Copying a VPS setup built for a different problem adds a machine you now have to patch, back up, and secure — for a publishing workflow that doesn't need one.
This post lays out the alternative: author and push from Claude Code on the web or your phone, let GitHub stay the deploy trigger it already is, and close the one real gap — a broken MDX file reaching production — with a small CI check instead of a VPS.
| Question | Short answer |
|---|---|
| Do I need a VPS for autonomous blog publishing? | No — not if GitHub already triggers your deploy |
| What's the actual laptop-bound step? | Just authoring + pushing the MDX file |
| What replaces the VPS? | Claude Code on the web or phone, pointed at the same repo |
| Does it pick up my writing voice? | Yes — the cloud session clones the repo, same as local |
| What's the safety net for bad posts? | A GitHub Actions MDX-validation workflow + Railway's "Wait for CI" |
| What's the real tradeoff? | Every content push triggers a full Next.js rebuild, not an instant static swap |
| When does a VPS make sense? | Deploy path is genuinely laptop-bound, or you need multi-hour always-on agent runs |
A VPS-and-tmux setup for autonomous agents earns its keep when the thing keeping the workflow alive is a machine that has to stay powered on and reachable — your laptop, specifically. Close the lid, lose the wifi, or let the machine sleep, and the agent session dies with it. Put the same session on a small cloud box instead, and it survives all three. That's the actual value: decoupling "the agent is running" from "my laptop is open."
The setup pattern is well documented for agents that expect to run continuously — see the remote-VPS install path in our Hermes Agent guide, which walks through Tailscale, UFW, and SSH access to a box that's designed to stay on indefinitely.
Blog publishing is a different shape of problem. Writing and pushing an MDX file is not a continuous process — it's a single, bounded task: draft, validate, commit, push. Nothing about it needs a machine that stays on between sessions. The only thing tying it to your laptop is that you happen to open your editor there.
Your repository already lives on GitHub, and Railway already watches main and redeploys on every push. That means the deploy trigger is already decoupled from any single machine — it's GitHub, not your laptop.
Open Claude Code on the web, or a mobile session, and point it at the same repository you use locally. Say "write a blog post on X and push." The cloud session:
git cloneCLAUDE.md, any blog-writing skill definitions, and your existing posts — so voice-matching works identically to a local session, because it's reading the same source materialRailway sees the push to main and deploys. Nothing here is a workaround — it's the same flow you'd use at your desk, just initiated from a phone or a browser instead of a terminal window. There's no second machine to provision, no Tailscale mesh to configure, no tmux session to keep alive.
This is also why running coding agents from a phone has become common for more than just blog publishing — the pattern of "any device that can reach the repo can drive the workflow" generalizes well beyond this one use case.
The part of this flow you're giving up, compared to a local session, is the chance to eyeball a build before it ships. When you're publishing from a laptop, you can run bun run build and skim the terminal output before pushing. When you're publishing from a phone on the train, you're not going to do that — and you shouldn't need to.
The fix is a small GitHub Actions workflow that runs on every push touching your blog content directory:
# .github/workflows/validate-blog.yml
name: Validate blog content
on:
push:
paths:
- 'apps/web/content/blog/**'
pull_request:
paths:
- 'apps/web/content/blog/**'
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: oven-sh/setup-bun@v2
- run: bun install
- run: bun run validate:mdx
- run: bun run validate:mdx:compile
Then flip on Railway's "Wait for CI" setting on the service. Railway checks the commit's GitHub status before triggering a deploy, so a broken MDX file — bad YAML frontmatter, an unclosed component, invalid JSX in the body — never reaches a build. You get a red ❌ on your phone from the GitHub check instead of a broken deploy in production. This is the same non-interactive discipline covered in our Claude Code CI/CD pipeline guide — pipelines need a hard pass/fail signal, not a human watching a terminal.
This is the only piece of new infrastructure in the whole design, and it's a few lines of YAML plus one toggle in a dashboard — not a server.
The tweet's underlying worry is: what if the machine that has to stay on is your laptop? For overnight, unattended, multi-hour agent runs — refactors, long research loops, anything using something like Claude Code's /goal command to work across many turns until a condition is met — that worry is legitimate, and a cheap VPS with tmux is a reasonable answer.
Blog publishing isn't that. The trigger is GitHub, not a process that has to stay resident. Anything that can commit to the repo — a laptop, Claude Code on the web, a phone — is already a valid publishing device. Adding a VPS to this picture means a second machine to patch, back up, and secure, in exchange for a property (device-independent publishing) you already have.
| VPS + tmux (levels.io style) | Claude Code web/phone + Railway | |
|---|---|---|
| New infrastructure | A cloud box you provision, patch, and secure | None — GitHub + Railway you already have |
| What stays "on" | The VPS, continuously | Nothing has to stay on between pushes |
| Best fit | Multi-hour autonomous agent runs, always-on tasks | Bounded tasks: draft → validate → push → deploy |
| Security surface | SSH keys, firewall rules, a machine to keep patched | Same GitHub/Railway auth you already manage |
| Setup effort | Provision box, Tailscale, UFW, tmux, agent install | Point an existing cloud session at your repo |
| Failure mode without a safety net | Runaway agent on an always-on box | A bad MDX file reaching a deploy — solved by CI |
Neither is objectively better — they solve different problems. The mistake is reaching for the VPS pattern by default because it's the visible, popular version of "autonomous agent workflow," when the actual bottleneck (a laptop-bound deploy trigger) doesn't exist in a setup where GitHub already deploys.
There's a genuine caveat worth naming rather than glossing over. Every blog push in an MDX-in-repo architecture triggers a full Next.js rebuild on Railway — the platform has to recompile the app, not swap a single file. That means "publish" takes however long your build pipeline takes, not the near-instant deploy you'd get from a framework built around static content updates.
This is inherent to keeping blog content as MDX files inside the same repo as the application code. It's not something the Claude Code web + Railway design introduces — it's the same cost a local push would pay.
If build time becomes a real bottleneck — dozens of posts a day, contributors waiting minutes to see a typo fix live — the deeper fix is loading posts at runtime instead of build time: from a database, or fetched from the GitHub API at request time, so publishing a post no longer triggers a full rebuild at all. That's a real architecture change, though, and not one worth making just to shave a rebuild for occasional publishing. Treat it as the next lever to pull if and when build time actually starts to hurt, not a default to reach for now.
To be direct about the limits of this design:
/goal pattern above, or a dedicated remote box, for that use case.This reflects a publishing workflow as of July 2026. Railway and GitHub Actions settings referenced here are subject to change — verify current configuration options in each platform's dashboard before relying on them for production deploys.