Once you have Codex CLI running on a private VPS, the next temptation is to install everything immediately.
Resist that.
A real self-hosted AI agent needs more than an install command. It needs a home for source code, configuration, secrets, state, logs, service restarts, scheduled jobs, and human approval. If you skip that planning layer, the server becomes a pile of scripts that happen to work until the first restart, expired token, missing log, or unclear side effect.
This is where Hermes-style workflow automation becomes different from a one-off coding assistant. You are not just asking an AI to edit a repo. You are preparing a small operating environment for repeatable developer automation and business workflows.
This public guide gives you the setup plan and safety model. The full Always-On Agents course keeps the exact command path, templates, service files, checklists, and launch support inside the preorder package.
Turn the public guide into a private, supported agent workflow.
The blog version gives you the strategy and safe setup shape. The preorder package is for the complete course, eBook, templates, update notes, and launch-cohort implementation support.
- Full VPS + Codex + Hermes command sequence
- Reusable skills, checklists, and templates
- Course + cheaper standalone eBook path
- DevelopJoy help if you want it implemented
Why planning comes before installation
Many workflow automation tools fail in the same way: the demo works, but the operating model is unclear.
On a VPS, unclear usually means:
- secrets are mixed into random
.envfiles; - state files live wherever the first script happened to run;
- logs are split between terminal scrollback, systemd, and forgotten files;
- a service restarts sometimes, but nobody knows why;
- the agent has more authority than the workflow deserves;
- nobody can tell whether the system did nothing, failed, or succeeded quietly.
That is not an AI problem. It is an operations problem.
The second module in the Always-On Agents sequence is deliberately about preparation. Before installing Hermes or OpenClaw, use Codex to inspect the server and draft a decision-complete plan. The plan should describe where things live, what can restart, what stays private, and what must never be exposed to the internet.
The baseline before this step
Do this after the first VPS foundation is already in place. At minimum, you should have:
- a private Ubuntu VPS;
- SSH key login;
- a non-root operator user;
- a firewall with only SSH open;
- Node.js/npm available;
- Codex CLI installed and authenticated;
- a workspace such as
~/agent-workflows; - no public agent endpoint yet.
If that baseline is missing, pause here. A Hermes runner is only as trustworthy as the box it runs on.
The public version of the first article is here: Codex CLI on a VPS: The Safer Foundation for an AI Coding Agent.
The planning prompt shape
The most useful prompt is not “install Hermes.” It is closer to:
The phrase “do not install Hermes yet” is doing real work. It keeps Codex focused on the operating environment instead of racing into a moving install target.
Fast-moving AI tools change. The server layout should stay boring.
A clean server shape
For a first self-hosted AI agent, keep the folder layout explicit:
The exact names can change, but the boundaries should not.
Use app for the checked-out runtime or service code. Use config for templates and environment references. Use logs for readable local logs. Use state for durable runtime state such as processed IDs, run ledgers, OAuth material, or dedupe caches. Use scripts for deterministic helpers that should not need a model call. Use skills for reusable workflow instructions and installable procedures. Use repos for project code the agent may inspect or modify with approval.
This separation makes the server easier to debug. It also makes future migration easier if you later move from a tiny VPS to a larger box or a managed deployment.
Secrets policy for the first version
Start conservative.
Real tokens should not go in prompts, blog posts, GitHub issues, screenshots, committed files, or support threads. Codex can help create templates, but it should not be handed production secrets just to draft a plan.
For a small private VPS, locked-down local environment files are usually enough at the start:
- keep secret-bearing files readable only by the operator or service user;
- commit only
.env.exampletemplates; - document required variables without including values;
- keep OAuth refresh tokens and API keys out of repos;
- rotate credentials if they were ever pasted into the wrong surface.
Later, a secret manager may make sense. For the first operator box, clarity and file permissions matter more than premature infrastructure.
systemd is part of the product
If Hermes becomes a long-running agent, it should not live as a forgotten terminal session.
The service plan should include:
- which Linux user runs the process;
- the working directory;
- the environment file path;
- the restart policy;
- where logs are read;
- how the service is enabled, stopped, restarted, and inspected;
- what should be verified before it is allowed to run unattended.
At this stage, the exact ExecStart can remain a placeholder. The point is to define the service boundary before the final install path is known.
That is a useful pattern for developer automation generally: decide the operating contract before locking in the tool-specific command.
Logging and state are not optional
An always-on workflow will eventually fail quietly unless it has logs and state.
Logs answer questions like:
- Did the scheduler run?
- Did the agent receive the trigger?
- Did an upstream API return no data?
- Did authentication fail?
- Did a side effect get blocked by an approval gate?
State answers different questions:
- Which items have already been processed?
- Which run created which output?
- Which OAuth account is connected?
- Which workflow is paused, blocked, or waiting for review?
If logs and state are scattered, debugging becomes a prompt-writing exercise. If they have stable paths, debugging becomes inspection.
That is the difference between an impressive demo and a workflow automation tool you can trust.
Firewall posture: private by default
For this phase, SSH should be the only public access path.
Do not expose:
- a raw Hermes control port;
- a shell-command endpoint;
- an unauthenticated debug dashboard;
- public logs;
- a webhook that can trigger broad side effects without verification.
If a later Discord, webhook, or dashboard layer needs public reachability, add an authenticated boundary on purpose. Use a tunnel, reverse proxy, webhook signature, bot auth, or private control channel depending on the actual workflow.
The first version should be useful from the shell before it becomes reachable from anywhere else.
What Codex should produce here
Codex is especially useful in this module because the work is specific and inspectable.
Ask it to produce:
- a server preparation plan;
- a folder creation script;
- a permissions validation script;
- a
.env.exampletemplate; - a systemd service draft with placeholders;
- a checklist for what to verify before enabling the service;
- a small diagnostics script that prints disk, memory, Node, npm, and Codex versions.
Do not ask it to paste real tokens. Do not ask it to expose the agent. Do not ask it to skip verification because the install seems obvious.
The best use of an AI coding agent here is to turn an operating plan into repeatable, reviewable files.
How this connects to Build Lean SaaS skills
A prepared VPS is also where installable skills start to matter.
A skill is a reusable workflow recipe: the context, scripts, templates, pitfalls, and verification steps needed to repeat a task. On a Hermes-style server, skills can live beside the runner and the repos they operate on.
That means an X bookmark workflow, content release watcher, GitHub issue triage loop, or client ops checklist can share the same runtime shape:
- deterministic scripts for cheap data collection;
- model calls only when reasoning is needed;
- dedupe state so items are not repeated;
- logs so failures are visible;
- approval gates before external side effects.
This is the bigger promise behind the course. The VPS is not the product. The reusable automation system is.
Turn the public guide into a private, supported agent workflow.
The blog version gives you the strategy and safe setup shape. The preorder package is for the complete course, eBook, templates, update notes, and launch-cohort implementation support.
- Full VPS + Codex + Hermes command sequence
- Reusable skills, checklists, and templates
- Course + cheaper standalone eBook path
- DevelopJoy help if you want it implemented
Keep moving through the public agent workflow trail.
These public guides stay focused on strategy, architecture, and safe operating models. The protected preorder package keeps the exact scripts, templates, command paths, and support loop.
The takeaway
Preparing a VPS for Hermes is not about memorizing one perfect install command. It is about designing a small, private, auditable home for self-hosted AI agent workflows.
Get the directories right. Keep secrets out of the wrong places. Decide how services restart. Make logs and state boring. Keep the firewall closed until there is a specific authenticated reason to open it.
Then the next layer—installing Hermes and connecting it to the way you already work—has a foundation worth trusting.