DEV Community: Andrey Markin

The AI-Ready Web: Why Every Website Needs Both a UI and an API

Andrey Markin — Wed, 12 Aug 2026 16:17:13 +0000

Every website will soon serve two interfaces — one for humans, one for AI agents. Exploring WebMCP, MCP servers, generative UI, and the architectural shift making websites AI-accessible.

Something strange is happening to the web. We're building a second version of it — not a redesign, not a rewrite, but an entirely parallel layer. One for humans, one for machines. And the interesting part? Most people haven't noticed yet.

Right now, you're reading this article in a browser. You navigated here, scrolled through a page, and your eyes are parsing styled text against a background. That's the human web — the one we've known for thirty years.

But there's another way to read this exact article. Add .md to the URL. You'll get the same content, stripped down to plain markdown — no HTML, no styling, no JavaScript. Just structured text, ready to be consumed by an AI agent, a CLI tool, or whatever comes next.

That's not a gimmick. That's a glimpse of where things are heading: every web service eventually serving two interfaces. The visual one you're used to, and a machine-readable one that most users will never see directly — but will interact with constantly through their AI assistants.

Services Without Interfaces

Rhys Sullivan, an engineer at OpenCode (previously at Vercel), posted something that stuck with me:

By the end of the year, you are going to be interacting with most services through their APIs and your assistant rather than their websites. I think there will also be some services that are purely API only intended to be interacted with just by your assistant.

When I read this, my first reaction was practical — I'd need to rewrite my Server Actions into API endpoints. Rhys's answer was telling: use oRPC, define your business logic once, and it works as both a Server Action (for your UI) and an OpenAPI endpoint (for agents). One source of truth, two consumers.

Since then, Rhys has been building executor — a local-first execution environment that puts this idea into practice. Instead of pasting large MCP manifests into every chat or giving an agent broad shell access, executor provides a unified tool catalog across MCP servers, OpenAPI APIs, and GraphQL endpoints. The agent discovers capabilities by intent, inspects schemas, and calls typed functions in a sandboxed TypeScript runtime. It's the local control plane for the agent-mediated web — connect your sources once, and every agent interaction goes through a structured, credentialed runtime rather than raw HTTP calls.

But the bigger point isn't about tooling. It's about the direction. We're moving from a world where the primary consumer of a web service is a human with a browser to one where it's an AI agent with an API client.

This isn't hypothetical. Stripe already shipped an Agentic Commerce Suite — a set of APIs designed specifically for AI agents to complete purchases autonomously. They co-developed an Agentic Commerce Protocol with OpenAI. You can literally say "buy that" inside ChatGPT and Stripe handles the transaction end-to-end, no website involved.

Cloudflare went even further. They shipped a Code Mode MCP server that exposes their entire platform — over 2,500 API endpoints — to AI agents. Not through a dashboard plugin or a browser extension. Through a server-side interface where the agent writes JavaScript against a typed API spec, executing in a sandboxed V8 isolate. Infrastructure management, fully agent-driven.

The API-only business isn't a prediction. It's already shipping.

WebMCP: The Right Idea, Wrong Layer?

Google and Microsoft clearly see the same future. They've co-authored a W3C proposal called WebMCP — a browser API that lets websites declare structured, callable tools for AI agents.

The concept is elegant: instead of an AI agent screen-scraping your website or parsing DOM elements to figure out what buttons to click, your site explicitly tells the agent: "Here are the things you can do, here are the parameters, here's the schema." The agent calls a typed function. No pixel-parsing, no guesswork.

I built a demo project to test this — a task manager app using Next.js and oRPC, with WebMCP tool registration bridging the two. It works. Chrome 146 Canary already ships an early implementation behind a flag. You can install the MCP-B Chrome extension and interact with any WebMCP-enabled site through an AI agent.

But here's my problem with it: WebMCP requires a browser.

The agent must visit a rendered page to discover available tools. It runs within the browser's JavaScript context. This makes sense for one specific use case — agentic browsing, where an AI controls a browser tab on your behalf. But that's not how most agent interactions actually work or will work.

Think about it. If you're asking Claude Code to interact with a service, there's no browser. If a background agent is processing your emails and booking meetings, there's no browser. If an API-only service exists purely for agent consumption — the kind Rhys predicts — there's no browser to render anything in.

WebMCP solves a real problem (structured agent-website interaction) but anchors the solution to the wrong layer (the browser rendering engine). What agents actually need is simpler: a server-side endpoint that describes available capabilities and accepts typed calls. That's... just OpenAPI. Or an MCP server. We arguably already have the tools; we just need the adoption.

It's telling that Cloudflare — a company that literally runs browser infrastructure — chose to go fully server-side with their agent interface. No browser rendering, no DOM, just typed API access in a sandbox. If anyone had reason to bet on the browser layer, it was them. They didn't.

The Agentic Browser That Nobody Switched To

There's a related observation that reinforces this. In 2025, we saw a wave of "agentic browsers" — Perplexity's Comet, OpenAI's Atlas, Microsoft Copilot in Edge. The pitch: your browser has a built-in AI that can navigate, fill forms, click buttons, and complete tasks for you.

And yet... I haven't switched. You probably haven't either. I use Chrome on desktop, Safari on mobile — like most people. When I need an agent to interact with the web, I use tools designed for it — direct API calls, MCP servers, or simple HTTP requests to structured endpoints.

The reason is subtle but important. Agentic browsing treats the existing visual web as the source of truth and puts an AI layer on top of it to interpret and navigate that visual layer. It's a workaround. It says: "The web was built for humans, so let's teach an AI to pretend to be a human using it."

That's the wrong abstraction. Instead of teaching agents to navigate human interfaces, we should give agents their own interfaces to the same services. The data and capabilities are the same — the access layer is different.

What Actually Works Today

Here's what I've found actually works for making a web service agent-accessible, without waiting for standards bodies or new browsers:

For content-heavy sites: serve a markdown version of every page. On my website, adding .md or .txt to any URL returns clean markdown. Sending an Accept: text/markdown header does the same. This is trivially simple to implement, requires zero special infrastructure, and works with every AI tool that can make HTTP requests.

It also enables concrete features for human users: "Copy as Markdown" and "Open in ChatGPT" buttons on every page. The agent layer and the human layer share the same content, accessed differently.

For application-heavy sites: expose your business logic as an OpenAPI spec. Tools like oRPC let you define a procedure once and use it as both a Server Action (for your React UI) and as a documented API endpoint (for agents). The agent doesn't need to "visit" your site — it reads your API spec, understands your capabilities, and calls them directly.

A good example of this in the wild: Flashcards, an open-source spaced repetition app built by Kirill Markin. It exposes a discovery endpoint that gives an AI agent everything it needs — authentication flow, available capabilities, OpenAPI spec — to sign up, create an account, and manage flashcard workspaces autonomously. You give your agent the discovery URL, confirm an email code, and it handles the rest. This is what an agent-first API looks like in practice: the web UI exists, but the API is the primary interface.

For discoverability: this is where it gets interesting, because the right approach depends on scale.

The Discovery Problem: Scale Changes Everything

Making your API agent-accessible sounds simple — just expose a spec. But in practice, there's a spectrum, and the right pattern depends on how many capabilities you're exposing.

Small surface (5–15 tools): Most web apps fall here. A task manager, a recipe site, a SaaS dashboard. For these, the agent can consume the entire API spec in one shot and generate typed tools from it. This is the pattern I'm exploring with OpenTools — a specification that extends OpenAPI with x-llm metadata (approval requirements, rate limits, natural-language hints for when to use each action) and makes the whole thing auto-discoverable via a /.well-known/llm.json endpoint. The agent fetches the manifest, reads the spec, generates tools dynamically, and starts calling them — no MCP server setup, no plugin installation, just a URL. Think of it as robots.txt for AI agents, but instead of telling crawlers what to index, it tells agents what they can do.

Large surface (hundreds or thousands of endpoints): Here, the "just read the spec" approach breaks down. Cloudflare learned this firsthand — their API has over 2,500 endpoints, which would consume 1.17 million tokens as a raw OpenAPI spec. No model can hold that in context. Their solution was Code Mode: instead of exposing thousands of individual tools, they give the agent just two meta-tools — search() to query the spec and find relevant endpoints, and execute() to call them. The agent discovers capabilities progressively, writing JavaScript against a typed API rather than consuming the whole schema upfront. Fixed token cost regardless of API size.

These aren't competing patterns — they're complementary. For most web applications, direct spec consumption works fine and keeps things simple. For platforms with massive API surfaces, progressive discovery is the way. Either way, the solution is server-side, typed, and doesn't require a browser.

These also aren't futuristic proposals. They're patterns you can implement today with existing tools. And they work with every type of agent — browser-based, CLI-based, embedded in chat interfaces, or running autonomously in the background.

The Output Side: Generative UI

So far I've been talking about the input side — how agents access services. But there's an equally interesting shift happening on the output side: how agents present results to users.

Vercel Labs recently released json-render, a framework by Chris Tate where AI generates constrained JSON specs that map to pre-defined UI components. The developer defines a catalog of allowed components (cards, tables, charts, metrics) with typed props. The LLM composes from that vocabulary. A renderer turns the JSON into actual React (or React Native) components.

This is significant because it reframes who designs the UI. Traditionally, every user sees the same dashboard, the same layout, the same arrangement of information. With generative UI, the interface adapts to the user's specific question or context. Ask for revenue data, and you get a dashboard with charts. Ask for a customer list, and you get a filterable table. The same backend, rendered differently each time.

But there's a practical constraint worth thinking about: token cost. If you want to render a table with 500 rows, you don't want the LLM generating that data token by token. The smart pattern is for the model to generate structure — "render a table component with this data source" — and let the client-side renderer handle the actual data population. Pass a reference to the data, not the data itself.

This is where json-render's approach shines. The LLM produces a lightweight JSON spec — maybe 2,000 tokens — that describes what to render. The heavy lifting (fetching data, rendering components, handling interactions) happens locally, outside the generation loop.

Google is working on something similar with A2UI — a protocol for agents to describe UI across trust boundaries. The difference: json-render is a tool (AI as a feature inside your app), while A2UI is a protocol (AI as a remote entity generating UI for a host application). Both point to the same future.

The Duality

Here's where I'm genuinely uncertain, and I think that uncertainty is worth admitting.

On one hand, the trajectory seems clear: agents will increasingly mediate our interactions with online services. The protocols are emerging (MCP, WebMCP, A2A, ACP). The infrastructure is being built (oRPC, json-render, agentic commerce APIs). Major companies are betting on it.

On the other hand... people still use regular websites. I still use regular websites. Muscle memory is powerful. When I want to check my bank balance, I open the bank's app — I don't ask an AI to query their API. When I want to buy something on Amazon, I browse. The behavioral shift required for the "agent-first" web is enormous, and humans change habits slowly.

I think what we'll see isn't a replacement but a stratification. Some interactions will move to agents quickly — repetitive tasks, multi-service workflows, data retrieval. Others will stay visual for a long time — browsing for inspiration, social media, content consumption where the UI is the experience.

The implication for builders is that you need to serve both. Your website still needs to be a great visual experience for humans. But it also needs a machine-readable layer — API endpoints, structured data, markdown export, capability declarations — so that when someone's AI assistant comes knocking, it can interact with your service without pretending to be a human clicking buttons.

What This Means for Developers

If you're building web applications today, the practical takeaway is straightforward:

Think in two layers. Your visual UI layer serves humans. Your API/data layer serves both humans and agents. Design the API layer first, then build the UI on top of it. This is good architecture regardless of the agent trend — but the agent trend makes it mandatory.

Expose your capabilities. If your app has functionality, make it callable. For most apps, an OpenAPI spec with agent metadata at a well-known URL is enough — agents can consume it directly and generate tools. For large platforms, consider progressive discovery patterns like Cloudflare's Code Mode. Either way, the businesses that are machine-discoverable and machine-callable will have a massive advantage — the same way SEO-optimized sites had an advantage when Google became the primary way people found things online.

Don't over-invest in agentic browser compatibility. WebMCP is interesting to watch but the spec is unstable and the browser-centric approach has fundamental limitations. Your time is better spent making your server-side APIs clean and well-documented.

Consider your content. If your site has valuable content (articles, documentation, product information), serve it in plain text or markdown alongside the HTML version. It's simple, it costs nothing, and it makes your content immediately accessible to every AI tool on the market.

Where I Think This Goes

I don't think we end up with one AI assistant that rules everything. We'll end up with something closer to the social media landscape — people use different platforms for different purposes. TikTok for entertainment, LinkedIn for professional networking, Twitter for real-time discourse. AI assistants will stratify the same way. You might use Claude for coding, ChatGPT for general tasks, Gemini for things deeply integrated with Google's ecosystem. People will have preferences, loyalties, workflows built around specific providers. The "one agent to rule them all" scenario is as unlikely as "one social network for everything" — we've seen how that plays out.

In the near term, the shift is clearest for transactional interactions. Anything you do today that involves opening an app, clicking through a workflow, and closing it — checking a balance, booking a flight, filing an expense, managing a subscription — will move to agents. Nobody enjoys those UIs. They exist because there was no alternative. Now there is.

The experience-first web survives. Browsing for inspiration, consuming content, social media — these stay visual because the interface is the product. You don't ask an agent to scroll Instagram for you. The utilitarian middle is what gets eaten.

But if I'm being honest about the longer arc, there's a more radical disruption waiting. We're currently bolting agent capabilities onto existing systems — adding API layers to websites, connecting assistants to services through protocols. The infrastructure of the web, the browser, the operating system — all of it was designed around the assumption that a human is directly manipulating a visual interface.

What happens when someone builds an operating system that doesn't make that assumption? An OS where the primary interface is an LLM-driven agent, where UI is generative — composed on the fly from the user's intent rather than pre-designed by a product team, where every application is just a set of callable capabilities that the system orchestrates and renders as needed. Not an AI layer on top of a traditional OS, but an OS built from the ground up around the agent paradigm.

That's the real disruption. Everything I've described in this article — the dual interfaces, the discovery protocols, the progressive API access — is a transition pattern. It's how we get from the human-first web to something fundamentally different. The question isn't whether it happens, but whether the transition is gradual enough for people to adapt, or whether someone ships the paradigm shift all at once and forces the industry to catch up.

Either way, the web isn't dying. It's growing a second nervous system — one designed for machines. The sites that develop both will thrive. The ones that remain human-only will gradually become invisible to an increasingly agent-mediated world.

That's not a threat. It's just the next layer.

Claude Code on VPS: Full Setup to Code from Your Phone

Andrey Markin — Mon, 10 Aug 2026 20:13:51 +0000

Complete guide to setting up Claude Code on a private VPS with Tailscale security, Tmux persistence, and Caddy HTTPS – code from anywhere, even your phone.

I wanted to code from my phone. Not "review PRs" or "edit a config file" – actually run Claude Code, iterate on features, and preview changes in the browser. Turns out a $7/mo VPS is all you need.

This guide covers the full stack: Hetzner VPS, Tailscale for zero-trust SSH, Tmux for persistent sessions, and Caddy for HTTPS dev server access. By the end you'll have a setup where you SSH in from your phone, attach a Tmux session with Claude Code already running, and preview your app at https://dev.yourdomain.com.

Architecture Overview

The setup has 5 moving parts:

Hetzner VPS – cheap, fast, EU/US datacenters. The machine where everything runs
Tailscale – mesh VPN. SSH traffic goes over encrypted Tailscale tunnel, never over public internet
Terminus – SSH client for iOS/Android/desktop. Connects to VPS via Tailscale IP
Tmux – terminal multiplexer. Sessions persist when you disconnect. Phone goes to sleep? Claude keeps working
Caddy – reverse proxy with automatic HTTPS. Exposes localhost:3000 at https://dev.yourdomain.com

VPS Setup

Go to Hetzner Cloud, create a project, spin up a server:

Location: closest datacenter to you
Image: Latest Ubuntu
Type: min: CX22 (2 vCPU, 4GB RAM, IPv4) – ~$7/mo, enough for me, but you choose you. If you run big projects and lots of parallel Claude instances, i would advise you get more memory

Hetzner sends the root password to your email. SSH in as root:

ssh root@<your-server-ip>

You'll be prompted to change the root password immediately on first login.

Non-Root User

Claude Code with --dangerously-skip-permissions refuses to run as root. Create a dedicated user:

adduser agent
usermod -aG sudo agent

# Copy your SSH key to the new user
mkdir -p /home/agent/.ssh
cp ~/.ssh/authorized_keys /home/agent/.ssh/
chown -R agent:agent /home/agent/.ssh
chmod 700 /home/agent/.ssh
chmod 600 /home/agent/.ssh/authorized_keys

# Switch to agent
su - agent

From now on, everything runs as agent.

Claude Code

Install Claude Code early – it can help you configure everything else on the server (Tailscale, firewall, shell, tooling, etc.).

# Install Claude Code
curl -fsSL https://claude.ai/install.sh | bash

# First run – authenticates via browser
claude

Follow the auth link. Once authenticated, you can use Claude Code to help with the remaining setup steps – or follow the guide manually.

Tailscale

Tailscale creates a zero-trust mesh VPN between your devices. Free for personal use (up to 100 devices). Every device gets a stable 100.x.x.x IP that works everywhere.

Install on VPS:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Follow the auth URL to link the VPS to your Tailscale account. Note the 100.x.x.x IP – that's your SSH target from now on.

Install Tailscale on your phone/desktop too. Once both devices are on the same Tailnet, they can reach each other directly.

Firewall (ufw)

Lock down the VPS. Only expose what's needed.

ufw is just a friendly front-end for the kernel's netfilter firewall – it isn't included on many minimal/VPS base images, so install it first:

sudo apt update
sudo apt install -y ufw

On other distros: sudo dnf install -y firewalld on RHEL/Fedora/CentOS/Rocky/Alma (or install ufw from EPEL), sudo apk add ufw on Alpine. The walkthrough below assumes Ubuntu/Debian.

Lockout warning: the rule below allows SSH only over the tailscale0 interface. If Tailscale isn't connected when you enable the firewall, you'll be locked out of the VPS. Before running sudo ufw enable:

Install ufw (above)
Confirm Tailscale is up: tailscale status
Open a second SSH session to the Tailscale IP (100.x.x.x) and keep it open – it's your safety net if a rule is wrong
Add the rules
Then enable the firewall

# Allow SSH only over Tailscale interface
sudo ufw allow in on tailscale0 to any port 22

# Allow HTTPS from anywhere (for Caddy dev server)
sudo ufw allow 443/tcp

# Enable firewall
sudo ufw enable

# Verify
sudo ufw status

Result: SSH is only accessible via Tailscale tunnel. Port 443 is open for the HTTPS dev server. Everything else is blocked.

Terminus SSH Client

Terminus is a cross-platform SSH client – works on iOS, Android, macOS, Windows. It's the best mobile SSH experience I've found.

Setup:

Install Terminus on your phone and/or desktop
Create a new host:
- Address: your VPS Tailscale IP (100.x.x.x)
- Username: agent
- Auth: SSH key (import your private key)
Connect – you're in

Tmux

This is the critical piece. Without Tmux, closing your SSH connection (or your phone going to sleep) kills whatever's running. With Tmux, processes keep running on the server – you just detach and reattach.

sudo apt install -y tmux

Essential Commands

# Create named session (name it after your project)
tmux new -s project1

# Detach from session (keeps it running)
# Ctrl+B, then D

# List sessions
tmux ls

# Attach to existing session
tmux a -t project1

# Kill a session
tmux kill-session -t project1

Parallel Workflow

Use one tmux session per project. Claude Code starts the dev server itself (in a background tmux session or via its built-in tools), so you just need one session to interact with:

# Project 1: your main project
tmux new -s project1
cd ~/project1
claude

# Detach: Ctrl+B, D

# Project 2: another project
tmux new -s project2
cd ~/project2
claude

# Detach: Ctrl+B, D

# Switch between projects:
tmux a -t project1
tmux a -t project2

Each project gets its own session. Claude handles dev servers, builds, and other processes within the session. Switch between projects as needed – everything survives SSH disconnects.

Parallel changes on the same repo? Use git worktrees. Worktrees let you check out multiple branches of the same repo into separate directories, so two Claude instances can work on different features simultaneously without conflicts:
cd ~/project1
git worktree add ../project1-feature-b feature-b
# Now run a separate tmux session for the worktree
tmux new -s project1-feature-b
cd ~/project1-feature-b
claude

Configuration

Optional but recommended .tmux.conf:

~/.tmux.conf

# Mouse support (useful for scrolling)
set -g mouse on

Reload with tmux source-file ~/.tmux.conf.

Shell & Tooling

Install the tools you'll need on the VPS. Here's what I'd recommend:

zsh + oh-my-zsh – better shell experience, autocompletions, plugins
git – version control, obviously
gh (GitHub CLI) – create PRs, open issues, review checks, all from the terminal
docker – if you run database instances, Redis, or other services locally
nvim – if you want to edit files in vim mode directly on the server
Dev runtimes – depends on your stack: bun, nvm (Node), python, uv, go, etc.

Once your shell is set up, add this alias to your .zshrc:

~/.zshrc

alias cc='claude --dangerously-skip-permissions'

This runs Claude Code in fully autonomous mode – no approval prompts for commands or file changes. Much better for async workflows where you kick off a task and come back later. But be cautious: in this mode Claude can do anything without asking, including pushing to main, running database migrations, deleting files, etc. Use it when you trust the task scope.

Project Config

Set up ~/.claude/CLAUDE.md so Claude Code understands your preferences from the start. This global config applies to all projects:

~/.claude/CLAUDE.md

# Claude Code Rules

## Environment
- **Platform**: VPS accessed via SSH from multiple devices
- **Shell**: zsh
- **Session management**: tmux (always assume running inside tmux)

## Communication Style
- Concise and direct response. Sacrifice grammar for the sake of concision.
- Minimal explanation unless asked
- No emojis

## Tmux Workflow
Since this is a VPS environment with SSH access from multiple devices, use tmux sessions for process isolation:

- **Long-running processes** (dev servers, watchers, builds): Create new tmux sessions
  ```bash
  tmux new-session -d -s <name> '<command>'
  ```
- **Naming convention**: `{project}-{purpose}` (e.g., `myapp-dev`, `api-build`) - prefix with repo/project name to avoid collisions across parallel instances
- **Checking output**: Use `tmux capture-pane -t <session> -p` to read session output
- **Listing sessions**: `tmux list-sessions`

This allows reconnecting from any device and finding all processes still running in their respective sessions.

## Tools Available
- git, gh (GitHub CLI)
- Standard Unix tools
- oh-my-zsh

## Plan Mode

- Make the plan extremely concise. Sacrifice grammar for the sake of concision.
- At the end of each plan, give me a list of unresolved questions to answer, if any.

You can adjust Tools Available section to include your coding environment like Bun, UV, etc.

The key VPS-specific addition is the Tmux Workflow section – it tells Claude Code to spin up long-running processes in separate tmux sessions instead of blocking the current terminal. This way Claude creates myapp-dev sessions for dev servers, and you can check their output or reattach from any device.

You can also add per-project CLAUDE.md files in each repo root for project-specific commands, architecture notes, and patterns. Claude Code reads both files automatically on startup. The easiest way to call /init inside Claude Code running in the project folder.

HTTPS Dev Server

Problem: Claude Code starts bun dev on localhost:3000, but you can't hit localhost from your phone browser. Solution: Caddy reverse proxy with automatic SSL.

DNS Setup

In your domain's DNS settings, add an A record:

DNS Record

Type: A
Name: dev
Value: <your-vps-public-ip>
TTL: 300

This points dev.yourdomain.com to your VPS public IP.

Caddy Setup

Caddy handles HTTPS automatically – it provisions Let's Encrypt certificates with zero config.

# Install Caddy
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Configure the Caddyfile:

/etc/caddy/Caddyfile

dev.yourdomain.com {
    reverse_proxy localhost:3000
}

That's the entire config. Caddy auto-provisions SSL and reverse-proxies to your dev server.

# Restart Caddy to pick up changes
sudo systemctl restart caddy

# Check status
sudo systemctl status caddy

Now when Claude starts bun dev in a Tmux session, open https://dev.yourdomain.com on your phone – live preview of your app with hot reload.

Security note: only port 443 is publicly exposed (for the HTTPS dev server). SSH stays locked behind Tailscale. If you don't need public HTTPS access, you can skip Caddy entirely and access the dev server over Tailscale too (http://100.x.x.x:3000).

Full Workflow

End-to-end, here's what coding from your phone looks like:

Open Terminus on your phone
SSH into VPS via Tailscale IP
Attach Tmux session: tmux a -t project1
Talk to Claude Code – describe the feature, fix, or change
You can close the app and break the connection. Claude edits files, runs commands, iterates
Preview changes: open https://dev.yourdomain.com in phone browser
Sessions keep running – come back anytime from any device

You can also run this from desktop with the same setup. The VPS becomes your persistent dev environment that you access from anywhere.

Telegram Bot Interface

I've been building a Telegram bot that acts as a chat interface to Claude Code on the VPS. Instead of opening an SSH client, you just message the bot from Telegram – it spawns Claude Code in the selected project directory and streams results back.

Key features:

Project switching – select which project directory to work in via inline keyboard
Voice messages – record a voice note describing what you want, the bot transcribes it (via Groq Whisper) and feeds it to Claude Code
Streaming responses – live-updated Telegram messages as Claude works
Conversation continuity – follow-up messages reuse the same Claude session
Cost tracking – each response shows token cost and duration

The workflow becomes: open Telegram, pick a project, describe a feature or fix (type or voice), and Claude Code does the work – edits files, runs commands, creates PRs. You get the output streamed back as Telegram messages.

It's built with TypeScript, Bun, and grammY. The project is open source – still early and has some rough edges, but I already use it daily for real work. Voice messages in particular make it feel like you're just talking to your dev environment.

Tips & Troubleshooting

Claude Code is slow / OOM

4GB RAM is tight if the project is large. Upgrade to CX32 (8GB) if needed
Close unused Tmux sessions to free memory

SSH connection drops frequently

Add to your SSH config:

~/.ssh/config

# ~/.ssh/config
Host vps
  HostName 100.x.x.x
  User agent
  ServerAliveInterval 60
  ServerAliveCountMax 3

Caddy not getting SSL cert

Verify DNS A record points to VPS public IP
Check port 443 is open: sudo ufw status
Check Caddy logs: sudo journalctl -u caddy

Tmux session lost scroll history

Increase history-limit in .tmux.conf
Use Ctrl+B, [ to enter scroll mode, q to exit

Phone keyboard tips

Terminus supports custom key mappings – map Ctrl, Escape, etc.
Use Tmux prefix Ctrl+A (easier to reach than Ctrl+B on phone keyboards)

Security checklist

SSH accessible only via Tailscale (never on public IP)
Keep system updated: sudo apt update && sudo apt upgrade
Tailscale ACLs for extra lockdown if sharing the Tailnet

FAQ

How much does it cost to run Claude Code on a VPS?

~$7/mo for a Hetzner CX22 VPS + Claude Code subscription ($20/mo for Pro, $100/mo for Max, $200/mo for 10xMax). Tailscale is free for personal use. Total: $27–207/mo depending on your Claude plan.

Can I run Claude Code on AWS, DigitalOcean, or Linode instead of Hetzner?

Yes. Any Ubuntu VPS with SSH access works. I use Hetzner personally, but DigitalOcean, Linode, and Vultr all work the same way. AWS EC2 works too but is more complex to set up and usually more expensive for equivalent specs.

Do I need Tailscale for VPS SSH, or is regular SSH enough?

I strongly recommend Tailscale. Exposing SSH on a public IP – even with key auth – means your server is one unpatched Ubuntu vulnerability away from being compromised. With Tailscale, the SSH port is never exposed to the public internet. There's nothing to scan, nothing to brute-force, no attack surface. You also get stable IPs across networks (home WiFi, mobile data, coffee shop) without port forwarding or dynamic DNS. Tailscale + ufw firewall is the baseline I'd consider safe for a development VPS.

What VPS specs do I need for Claude Code? (CPU, RAM, storage)

2 vCPU / 4GB RAM handles one Claude Code instance and a dev server fine for small-to-medium projects. For larger projects or running multiple Claude instances in parallel, go 4 vCPU / 8GB RAM. Disk is rarely the bottleneck – 40GB is plenty unless you're running Docker images.

Can I use VS Code Remote SSH with Claude Code?

Yes, VS Code Remote SSH works over Tailscale. But you lose the main benefit – working from your phone. The terminal-only workflow is intentional: Claude Code does the editing, you just direct it. If you prefer visual editing, VS Code Remote SSH + Cursor is a valid alternative for desktop.

Is Claude Code `--dangerously-skip-permissions` safe to use?

I run everything with --dangerously-skip-permissions. The reason it works for me: this is a VPS, not my personal laptop. If Claude somehow destroys the environment, I don't lose anything irreplaceable – only project files (backed by git) and dev-only environment variables. No production credentials, no personal data.

That said, in this mode Claude can theoretically run rm -rf, git push --force, or drop a database without asking. To mitigate this, Claude Code supports hooks – shell scripts that intercept commands before execution. You can set up safeguards like: block rm -rf / patterns, prevent git push --force to main, or enforce drizzle-kit migrate instead of drizzle-kit push. Hooks give you the speed of autonomous mode with guardrails where they matter.

How to set up a shared VPS for multiple developers with Claude Code?

Create separate Linux users, each with their own home directory, tmux sessions, and Claude Code auth. Tailscale ACLs can restrict who can SSH in. Each user's projects stay isolated.