The first server tutorial gets you to a simple point: a VPS exists, Codex CLI works, and you can safely inspect the machine.
This article is the bridge between that box and a real Hermes-style agent workflow.
The important move is to avoid pretending this is only an install command. Before Hermes runs, the server needs a shape:
- Where does the agent live?
- Where do secrets live?
- Where does state live?
- Where do logs go?
- What should systemd restart?
- What should never be exposed to the public internet?
Codex is useful here because the job is mostly planning and setup. It can inspect the box, draft scripts, and make the operating decisions explicit before you commit to a specific Hermes install path.
Follow the Always-On Agents course path
Follow the complete public course path, install the skills as you go, and use DevelopJoy when you want the workflow wired into your actual VPS.
What this guide does and does not do
This guide prepares the server for Hermes-style work.
It does not lock in a specific Hermes repository or package source yet. That should be confirmed against the exact Hermes/OpenClaw setup you want to run.
That constraint is intentional. Server layout is stable. Fast-moving agent installs are not.
The job here is narrower: use Codex to prepare the box, document the decisions, and avoid a sloppy install where secrets, state, source code, and logs all end up in one directory.
Start from the VPS baseline
Before this guide, complete:
You should already have:
- Ubuntu VPS.
- Non-root user.
- SSH key login.
- Firewall enabled.
- Node.js installed.
- Codex CLI installed and authenticated.
- A workspace folder like
~/agent-workflows.
Use planning mode first
From the server:
Then ask for a plan before making edits:
The important line is "do not install Hermes yet."
You want the agent to reason about the operating environment first. That keeps the first pass focused on structure, permissions, and safety instead of chasing a moving install target.
Failure modes to avoid
This setup is mostly about avoiding preventable mistakes:
| Mistake | Why it hurts |
|---|---|
| Real tokens in prompts or repo files | They leak into logs, shell history, screenshots, or commits. |
| Raw Hermes port on the public internet | Anyone who reaches it may be able to poke the agent surface. |
| No restart policy | The agent dies once and silently stops being useful. |
| Scattered state files | OAuth tokens and processed IDs get lost during cleanup. |
| No log path | Debugging turns into guessing. |
If Codex suggests a shortcut that breaks one of those boundaries, stop and re-plan. The point of this post is to make the server boring before it becomes useful.
Recommended folder shape
Use a boring layout:
The exact names can change. The separation should not:
appfor the checked-out Hermes code or runtime.configfor non-secret config templates.logsfor readable local logs.statefor durable runtime state.scriptsfor setup and maintenance scripts.skillsfor installable agent workflows.
OAuth refresh tokens, Linear state, bookmark state, and long-running agent memory should not live in random working directories.
Secrets policy
For a small personal VPS, start with environment files that are readable only by the agent user.
Example:
Use Codex to create templates, not real secrets:
The final install can decide whether to keep local env files, use a secret manager, or move secrets into provider-specific infrastructure. For this first VPS lane, locked-down env files are enough.
Never paste production secrets into an article, prompt transcript, GitHub issue, or support thread. Use placeholders in docs and put real values only on the server.
systemd service shape
Hermes should eventually run as a service, not as a forgotten terminal process.
Ask Codex to draft a service without enabling it:
The service will probably look conceptually like this:
Treat that as a shape, not final code. The real ExecStart depends on the confirmed Hermes install.
Logging
A useful agent server needs boring logs.
At minimum:
Then decide whether logs come from:
journalctlthrough systemd.- Application log files in
logs/. - Both.
For a first setup, systemd logs are usually enough:
Once the workflow starts creating tasks, reading bookmarks, or receiving chat messages, logs become part of the product surface. They are how you tell the difference between "the agent is broken" and "the upstream API returned nothing."
Firewall posture
Keep the server closed by default.
At this stage, SSH is the only required public port. Hermes should not be exposed directly unless you have a specific authenticated interface in front of it.
Good defaults:
- SSH only.
- No public Hermes port.
- Webhook/chat integrations should use a narrow authenticated endpoint, tunnel, or reverse proxy later.
- Avoid putting a raw agent API on the open internet.
What not to expose:
- A raw Hermes control port.
- A shell-command endpoint.
- A debug dashboard with no auth.
- Logs that include prompts, tokens, or customer data.
Use Codex for setup scripts
Once the plan looks right, ask Codex to create small scripts:
This is exactly where Codex is strong. It can turn the plan into repeatable checks without inventing the product.
Connect this to skills
This server is also where Build Lean SaaS skills start to make more sense.
For example, the X bookmark skill can live alongside Hermes:
Hermes, Codex, or another runner can read the skill instructions and call the bundled script later. The server gives those skills a stable home.
Want help preparing your VPS for an agent runner?
Use this as the planning checklist, or pair with DevelopJoy when you want the directories, secrets, service shape, logs, and skill workflow reviewed before you run a long-lived agent.
Build it with us
Pair-programming lab
$100/moHave us build it
Done-for-you focus sprint
Starts at $500/moWhat comes next
After Hermes has a clean server home, install the runtime, then give it a private Discord control channel.
Those are the next guides: