DEV Community: EQVPS

Self-host n8n on a VPS with Docker

EQVPS — Thu, 25 Jun 2026 09:12:20 +0000

n8n is the kind of tool you start using lightly and then quietly route half your operations through. At which point "it's running on someone's cloud seat, metered per execution, with my API keys living on their servers" starts to feel less great. Self-hosting fixes all three — flat cost, no execution cap, and your keys stay on a box you own. With Docker it's a fifteen-minute job.

How much server it actually needs

Honest numbers first, so you don't over- or under-buy:

~2 GB RAM is the sweet spot — n8n plus its Postgres database plus normal workflows sit comfortably here.
1 GB works if your workflows are light, but you'll notice it on bigger runs.
4 GB if you do heavy parallel executions or push large payloads through.

n8n isn't CPU-hungry at rest; it spikes during runs. A 2-core box is fine for most setups. (More on matching specs to workload in the sizing guide.)

The Docker setup

On a fresh Ubuntu/Debian box, install Docker:

curl -fsSL https://get.docker.com | sudo sh

Make a folder and a docker-compose.yml — n8n with a persistent volume and Postgres:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=db
      - DB_POSTGRESDB_PASSWORD=change-me
    volumes:
      - ./n8n-data:/home/node/.n8n
    depends_on: [db]
  db:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_PASSWORD=change-me
      - POSTGRES_DB=n8n
    volumes:
      - ./db-data:/var/lib/postgresql/data

sudo docker compose up -d

Two things worth pointing out: the volumes (n8n-data, db-data) are what keep your workflows alive across restarts and upgrades — don't skip them. And n8n is bound to 127.0.0.1, not 0.0.0.0 — it's not exposed to the internet directly. That's deliberate; the next step handles access safely.

Access: HTTPS or a tunnel

Public URL (needed for OAuth nodes and webhooks): point a subdomain at the server and run a reverse proxy (Caddy is the least-effort — automatic HTTPS) in front of 127.0.0.1:5678. This is where a dedicated-IP plan fits, since you control ports and DNS.
Just for yourself, no domain: skip the proxy and reach it over an SSH tunnel — ssh -L 5678:127.0.0.1:5678 user@server, then open localhost:5678. Works fine on a NAT VPS.

Lock it down and keep it up

n8n holds your API keys and credentials, so the box must be tight: do the security checklist (SSH keys, firewall, no password login) before you put real credentials in. restart: always in the compose file already means Docker brings n8n back after a crash or reboot — that's your uptime handled.

Is it worth it?

Be honest with yourself about volume. If you run automations constantly, self-hosting wins on cost (flat vs per-execution) and removes any workflow/run limits. If you trigger a few flows a month, a hosted seat is less hassle. But the control argument stands regardless: your workflows, your data, your keys — on your server, not rented. For most people who got serious about n8n, that's the deciding factor.

A 2 GB box, a compose file, a domain (or a tunnel), and you're running your own automation hub — payable in crypto with no KYC, live in minutes.

FAQ

How much RAM does self-hosted n8n need?

Around 2 GB is the comfortable sweet spot for n8n plus its Postgres database and normal workflows. It runs in 1 GB if workflows are light, but you'll feel it during bigger runs. Heavy parallel executions or large payloads — go to 4 GB.

Do I need Docker to self-host n8n?

It's by far the easiest way — one compose file gives you n8n, a database and persistent storage, and upgrades are a single pull. You can install via npm instead, but Docker saves you the dependency and upgrade headaches.

Is self-hosting n8n cheaper than n8n cloud?

If you run a steady stream of automations, yes — a flat monthly VPS beats per-execution pricing, and there's no workflow or execution cap. For a handful of runs a month, a hosted seat may be simpler. The other reason people self-host is control: your data and API keys never leave your server.

Do I need a domain for n8n?

For OAuth-based nodes (Google, etc.) and clean HTTPS, yes — point a domain at the server and put n8n behind a reverse proxy with a certificate. For purely internal use you can reach it over an SSH tunnel without a domain.

Can n8n run on a NAT VPS or do I need a dedicated IP?

Internal/SSH-tunnel use works on a NAT box. If you want a public URL with your own domain and HTTPS (needed for some OAuth callbacks and webhooks), a dedicated-IP plan is the cleaner fit since you control all ports.

Originally published at eqvps.com.

How an AI agent buys and runs its own server over MCP

EQVPS — Wed, 24 Jun 2026 11:54:21 +0000

An AI agent can write a scraper, debug it, and tell you exactly where to deploy it. Then it stops. Because the next step — actually renting the server — almost always needs a human: open an account, maybe pass an identity check, type a card number into a checkout. The agent did the hard part and now waits on you for the boring part.

That gap is the whole reason this exists. We took the human out of the middle.

Where autonomy usually breaks

Think about what "renting a server" really involves on a normal host. A signup form. An email to confirm. Billing details, sometimes ID. A card at checkout. A dashboard to find the IP. Every one of those assumes a person sitting there.

An agent can't sit there. It can call an API, hold a token, make decisions — but it can't receive a verification email or pull out a credit card. So the moment infrastructure enters the picture, the autonomous workflow turns back into a human workflow with extra steps. You wanted an agent that ships; you got an agent that files a ticket.

The flow, end to end

On EQVPS the same actions are MCP tools (16 of them) plus a REST API — and crucially, the agent can get its own credentials. Here's the actual sequence:

// 1. Get an account — token comes back immediately, no email, no human
register_account({ first_name: "Ada", last_name: "Agent", email: "ada@example.com" })
//    → { token: "..." }   send it as Authorization: Bearer <token> from here on

// 2. See what's available
list_plans()
//    → plans with specs, prices, and OS image ids

// 3. Make sure there's money on the balance
get_balance()
//    → { balance: 25, currency: "USD" }

// 4. Order — this debits the balance and provisions the box
order_vps({ product: "nano", os_id: 1, hostname: "ada-worker" })
//    → { service_id, paid_from_balance: true }

// 5. Read the keys to its own new server
get_vps_status({ service_id })
//    → { ip, ssh_port, password }   ~60 seconds after ordering

Five calls and the agent is SSH'd into a machine it rented itself. No dashboard, nobody approving each step. If you'd rather drive it from plain HTTP, the same endpoints exist over REST — MCP or REST, your call.

The honest part: what's automated, what isn't

Ordering is fully autonomous. Funding the balance isn't — not yet. Right now someone puts crypto on the balance once (USDC/USDT, or a card on-ramp), and from that point the agent orders, scales and cancels on its own, spending only what's there.

The end state everyone pictures — an agent paying on-chain, per request, with no pre-funding — is the x402 style, and we think it's where this goes. We haven't wired it up. It needs USDC-settled rails and a few things we don't run today, so rather than slap "fully autonomous payments" on the box, here's the truth: autonomous ordering now, autonomous funding later. The prepaid balance is the bridge, and honestly it doubles as a spend cap you probably want anyway.

A couple of real details

The MCP server speaks Streamable HTTP at https://mcp.eqvps.com/mcp, so it drops into any MCP client without a local shim. Auth is a Bearer token the agent mints itself with register_account — the same token works across MCP and REST, against the same account and balance. Sessions are tracked server-side, so a long-running agent can hold one connection and keep calling tools.

One practical note from running this: treat the token and the returned root password like the secrets they are. The agent should store them, not echo them into logs or chat. The balance caps the financial blast radius; basic secret hygiene caps the rest.

Why it matters

For now most of our actual customers are humans who happen to like paying in crypto — we're not going to pretend the web is overrun with autonomous agents buying servers. But the direction is clear. As agents take on longer, real tasks, "can it get and run its own infrastructure?" stops being a party trick and becomes a requirement. When that day fully arrives, the rails need to already be there.

They are. Add the MCP server to your agent — start with connecting an MCP client — fund a small balance, and let it rent its first server. About a minute to root.

FAQ

Can an AI agent really buy a server on its own?

Yes — the ordering part is fully autonomous. Over our MCP server the agent calls register_account to get a token, then order_vps, which spends from a prepaid balance and provisions the VPS. It reads back SSH access from get_vps_status. No human clicks through a checkout. The one thing a human (or a funded agent wallet) does first is put crypto on the balance; after that the agent runs on its own.

How does the agent pay?

From a prepaid balance. You fund it once with USDC or USDT (or a card via the on-ramp), and order_vps debits that balance per order. The agent never holds your wallet keys, and it can't spend more than what's on the balance — which is also your safety cap.

What is MCP provisioning?

MCP (Model Context Protocol) lets an agent call tools directly inside clients like Claude, Cursor or Cline. 'MCP provisioning' just means the whole rent-a-server flow — register, pay, order, get root — is exposed as MCP tools the agent calls itself, instead of a web dashboard a person clicks.

Is this fully hands-off?

Ordering is. Funding isn't quite there yet: today someone tops up the balance with crypto, and then the agent is autonomous. Fully on-chain per-request payment (the x402 style) is on our radar but not wired up — we'd rather say that plainly than pretend.

What does the agent need to get started?

Just the MCP server URL (https://mcp.eqvps.com/mcp) added to its client. It calls register_account and gets a Bearer token in the response — no email confirmation, no human step. From there every action is a tool call.

Originally published at eqvps.com.