If you are searching for Codex CLI, OpenAI Codex CLI, or an AI coding agent that can do real work, the first question is not which prompt to use.
The first question is where the agent should live.
Running Codex from your laptop is fine for experiments. It is not a great foundation for recurring workflow automation. Your laptop sleeps, changes networks, loses terminal sessions, and mixes agent state with whatever else you are doing that day. A small private VPS gives the workflow a boring, persistent home: one server, one operator account, one place for repos, logs, state, credentials, and scheduled jobs.
That is the point of the first module in the Always-On Agents course. This public version gives you the architecture, decision checklist, and safe setup shape. The full course keeps the exact command sequence, templates, support notes, and update path 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 a VPS changes the agent workflow
A useful AI coding agent needs more than a chat box. It needs a place to inspect files, run commands, remember state, produce logs, and hand work back to you for approval. When that place is your daily laptop, the workflow stays fragile.
A VPS gives you a cleaner boundary:
- The agent can run from a machine that stays online.
- Secrets and OAuth state can live in one controlled environment.
- Scheduled jobs can write logs and state without depending on your MacBook being awake.
- Repositories can be cloned, inspected, and updated from a stable workspace.
- Future Discord, email, bookmark, or content watcher workflows can reuse the same foundation.
The goal is not to expose an autonomous bot to the public internet. The goal is a private operator box that you can SSH into and control.
That distinction matters. A server is not safer because it is remote. It is safer when the scope is narrow, the ports are boring, and the agent cannot surprise you with public side effects.
The starter architecture
For a first AI coding agent VPS, keep the architecture small:
- A low-cost Ubuntu VPS.
- SSH key authentication.
- A non-root operator user.
- A firewall with only SSH open at the start.
- Node.js/npm available for Codex CLI and small scripts.
- A dedicated workspace directory for repos, skills, state, and logs.
- No public webhook, bot, dashboard, or exposed agent endpoint yet.
That last item is the most important. The first version should be useful before it is clever. You want a place where Codex can help you plan and implement, not a public automation surface with unclear authority.
Once the server is stable, you can layer on Hermes, Discord approvals, Google Workspace, X bookmark capture, or content release watchers. But those should be follow-on modules, not day-one complexity.
What to decide before creating the server
Before you spin up a Droplet or another VPS, answer these questions:
- Will this server hold personal or client data?
- Which account owns the server and billing?
- Who can SSH into it?
- Where will API keys and OAuth tokens live?
- What happens if the server is compromised?
- What workflows are allowed to write files, send messages, create tickets, or change production systems?
Most builders skip this because it feels slow. It is faster than cleaning up a confused agent runtime later.
For the starter setup, I prefer a narrow answer: one private server, one operator account, SSH-only access, no public agent endpoints, and explicit approval before any workflow sends email, schedules meetings, writes GitHub issues, or posts to Discord.
What the public setup should prove
The first milestone is not “the agent is autonomous.” The first milestone is much smaller:
- You can SSH into the box reliably.
- You are not using root as the daily working user.
- Password login is disabled.
- The firewall is enabled.
- Codex CLI can run in a controlled workspace.
- Logs and state have obvious homes.
- Nothing agent-related is publicly reachable.
If those are true, the machine is ready for the next layer. If those are not true, adding more automation only creates more places for the setup to fail.
This is also why I like starting with a cheap VPS instead of a complex cloud stack. For the first version, you do not need Kubernetes, multi-region architecture, or a dashboard. You need a small box that stays online and can be understood in one screen.
The workspace shape
A simple folder layout keeps future agent work from turning into a junk drawer. The exact names matter less than the separation:
reposfor cloned codebases.skillsfor reusable instructions and workflow recipes.statefor dedupe files, caches, OAuth material, and run ledgers.logsfor cron output and agent run summaries.scriptsfor deterministic helpers that should not require a model call.
That layout supports the bigger Always-On Agents pattern: scripts collect or verify facts cheaply; agents reason only when reasoning is needed; side effects stay approval-gated until the workflow earns trust.
It also makes debugging much easier. When a daily watcher misses something, you can inspect state and logs instead of asking a model to remember what happened.
What to avoid in the first pass
The fastest way to make this fragile is to combine too many goals:
- Do not expose a public web server just because the VPS can run one.
- Do not wire Discord commands before the private shell workflow is stable.
- Do not store secrets in random repo files.
- Do not give the agent broad production credentials on day one.
- Do not skip logging because the workflow “usually works.”
- Do not treat autonomous execution as the default success metric.
The better first pass is boring: private SSH access, one workspace, clear logs, and manual approval for anything that leaves the server.
How this becomes an always-on agent
Once the foundation is stable, the course path gets more interesting:
- Use Codex planning mode to prepare the VPS for a Hermes/OpenClaw-style runtime.
- Install Hermes and define the service boundary.
- Connect a private Discord channel as the command center.
- Add one real workflow, such as X bookmark capture or client email triage.
- Add scheduled heartbeats, dedupe state, and approval prompts.
- Keep improving the workflow from logs instead of vibes.
That is when “AI coding agent” becomes more than a repo helper. It becomes a small operating system for repeatable business automation.
But the foundation still matters. If the server is messy, the workflow will be messy. If the server has clear boundaries, every later module is easier to reason about.
Public checklist
Use this as the lightweight version of the module checklist:
- Choose a small Ubuntu VPS.
- Use SSH keys, not password login.
- Create a non-root operator user.
- Enable a firewall and keep only SSH open at first.
- Install only the basics needed for Codex CLI and repo work.
- Create dedicated folders for repos, skills, state, logs, and scripts.
- Keep secrets out of committed files.
- Run the first agent tasks in read-only or approval-gated modes.
- Add scheduled jobs only after manual runs are boring.
- Delay public bots/webhooks until the private workflow is proven.
This will not give you the full supported course environment. It will give you the right mental model: small, private, persistent, auditable.
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
Codex CLI is useful because it can operate close to the code. A VPS is useful because it gives that operation a stable home. The combination is powerful when you keep the authority boundary tight: private server first, approval-gated workflows second, public automation last.
That is the foundation for the Always-On Agents sequence. The public article should help you decide if the approach fits. The full course and eBook package are for turning it into a working system with the complete templates, command path, and support loop.