A private VPS with Codex CLI is a good start. A prepared directory layout, secrets policy, and logging plan are better.
But the moment the system becomes useful is when you install the actual runtime: the local AI agent process that can receive tasks, run controlled workflows, keep state, write logs, and report back to a human operator.
For the Always-On Agents course, that runtime is Hermes/OpenClaw-style infrastructure: a private command surface for agent work, not a public chatbot endpoint. The goal is not to “put an AI on the internet.” The goal is to give a business a reliable private operator that can help with repeatable workflows without exposing a raw control port.
This public guide covers the install model, runtime boundary, and safety checklist. The full course keeps the exact command path, templates, service files, rollback notes, 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
What you are installing
When people search for AI agents for business, they often picture a polished app: a chat box, dashboard, or automation builder.
Underneath that interface, the useful part is usually more boring:
- a process that can run on demand or stay alive;
- a workspace where repos, scripts, prompts, and outputs live;
- a secrets layer that is not committed to Git;
- logs that prove what happened;
- a health check that says whether the runtime is alive;
- a restart policy that survives deploys and server reboots;
- a human approval path for side effects.
That is the layer Hermes/OpenClaw should occupy on your VPS.
It should not be a public service that anyone can hit. It should not be a pile of one-off shell history. It should be a private runtime with a clear boundary: local commands in, controlled workflow execution out, durable logs behind it.
The baseline before installation
Do this after the first two foundation steps are complete:
At minimum, the server should already have:
- a non-root operator user;
- SSH key access;
- a firewall that only exposes required ports;
- a workspace such as
~/agent-workflows; - directories for app code, logs, state, secrets, backups, and scripts;
- a decision about what runs as a service versus one-off commands;
- no public agent port.
If that foundation is missing, pause. Installing the runtime first makes every later decision messier.
The private agent boundary
A safe first install should look like this conceptually:
The important part is what is not in that diagram: a public Hermes control surface.
For a small business automation agent, public exposure is rarely necessary at the beginning. Discord, email, webhooks, X bookmarks, GitHub issues, and scheduled jobs can all be added as controlled integrations later. The first install should prove that the runtime works locally before anything else is allowed to send it work.
Use Codex as the installation operator
The best use of Codex here is not to blindly paste a universal install command. Fast-moving agent tools change names, package managers, environment variables, and recommended service shapes.
Use Codex to inspect the server you actually prepared and turn the install into an explicit plan.
The public prompt shape is:
That keeps the work grounded in your server instead of a stale tutorial.
In the paid course, this step becomes a concrete implementation walkthrough with the command sequence, service template, validation checklist, and rollback path.
Runtime checklist for a business agent
Before connecting Discord or any external workflow, verify the runtime against this checklist:
- It starts as the non-root agent user.
- It reads configuration from the agreed environment file location.
- Real secrets are not committed to Git.
- Logs land in the expected log directory.
- State survives restarts.
- A status or health command exists.
- Restart behavior is documented.
- The firewall still exposes only the minimum required surface.
- The runtime can be stopped cleanly.
- There is a rollback path if an update breaks the install.
- Human approval is still required before high-risk side effects.
This is the difference between a private AI agent and a cool demo. The demo only has to work once. The business agent has to be inspectable after it runs.
Why systemd is still the boring answer
If the runtime needs to stay alive, let the operating system manage it.
For a VPS, that usually means a systemd service with:
- a dedicated user;
- a fixed working directory;
- an environment file;
- a single start command;
- restart-on-failure behavior;
- logs visible through the journal;
- no public bind unless you explicitly need one.
You do not need a complex container platform for the first Always-On Agents install. You need boring service management, clear files, and predictable recovery.
The exact service file depends on the chosen runtime command. That is why the course treats the service template as a checklist, not as a copy-paste artifact for every server.
Health checks before integrations
A private AI agent is not ready just because the install command exits successfully.
Before you connect Discord, GitHub, X bookmarks, or business process automation, you should be able to answer:
- Is the service running?
- Where are the last 80 log lines?
- What command proves the runtime can accept work?
- What command proves the security posture is still acceptable?
- What changed on disk during the install?
- How do I stop it?
- How do I roll it back?
If those answers are fuzzy, the next integration will hide the problem rather than solve it. A chat channel can make an unstable runtime feel friendly, but it does not make it operational.
What this unlocks next
Once the runtime is private, local, and observable, the system becomes ready for a control channel.
That is when Discord starts to make sense. The chat layer should not be the agent. It should be the human-friendly interface to a runtime that already knows where logs, state, secrets, and approvals live.
From there, the Always-On Agents path can move into practical business workflows:
- routing tasks from Discord;
- turning messy notes into GitHub issues;
- watching X bookmarks for opportunities;
- drafting implementation plans;
- handing work to coding agents;
- reporting status back to a human owner.
That is the real wedge for AI agents for business: not another generic assistant, but a private operator that helps the business turn repeated work into controlled workflows.
The takeaway
Install Hermes/OpenClaw only after the VPS has a clear operating shape.
Keep the first runtime private. Give it logs, state, health checks, restart behavior, and rollback. Do not expose a raw control port just because the tool can run one. Connect external integrations only after the local runtime is boring.
That boring foundation is what makes the later automation exciting.
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.