Codex on a VPS: Set Up an Always-On AI Development Box

The X bookmark bot sounds simple until you ask where it should live.

If it runs on your laptop, it is not really daily automation. Your laptop sleeps, changes networks, runs out of battery, and gets rebooted right when the job is supposed to run. That is fine for experiments. It is not the foundation I want for a personal agent workflow that checks bookmarks, writes state, and creates Linear tasks every day.

So before the bookmark sync, we need a small server.

This guide sets up a private Ubuntu VPS for Codex CLI. Nothing fancy. The goal is a boring little box you can SSH into, keep online, and use as the home for future Codex, Hermes, cron, and chat-driven agent work.

Course 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.

Public walkalong guide

Installable skills

DevelopJoy setup path

Open the courseGet setup help

What we are building in this series

This is the foundation article.

The complete path looks like this:

1. Create a small DigitalOcean Droplet and install Codex CLI.
2. Use Codex planning mode to prepare the server for a Hermes-style runner.
3. Add a private chat surface so you can talk to the agent from where you already work.
4. Run a real workflow, starting with X bookmark capture into Linear Triage.

This post only gets the server online. That is still the step the rest depends on. Once the server is stable, the later pieces stop being loose scripts and start becoming a workflow you can trust.

What this needs from you

I am choosing a narrow path on purpose. The point is not to compare every VPS provider or optimize every dollar. The point is to get a reliable server online quickly, then use Codex to help with the next layer.

You need:

• A DigitalOcean account.
• An SSH key on your local machine.
• A small budget, usually about $4-8/month before backups.
• ChatGPT sign-in or an OpenAI API key for Codex CLI.
• A willingness to keep the first version private.

That last point matters. Do not start by exposing a bot to the internet. Start with a private operator box that can hold state, run scheduled jobs, and become the home for your agent workflows.

Affiliate disclosure

Some links in this series may become affiliate or referral links. If that happens, the recommendation will stay the same: this tutorial uses DigitalOcean because it is the clearest path for this exact setup.

Why this tutorial uses DigitalOcean

DigitalOcean is the right default for this series because it removes setup friction.

For this kind of project, you do not need a complicated cloud account. You need a small Ubuntu server, SSH access, predictable billing, snapshots or backups when the workflow matters, and docs that are easy to follow when something breaks.

DigitalOcean Droplets fit that job well:

• The Droplet flow is direct: choose Ubuntu, add an SSH key, pick a small plan, create the server.
• Basic Droplets are cheap enough for personal automation.
• The dashboard is clear without hiding the server details.
• Backups, snapshots, monitoring, firewalls, and resizing are easy to find later.
• The docs are good enough for a beginner to recover when setup gets weird.

Last checked on May 11, 2026, DigitalOcean lists entry Basic Droplets from $4/month, with predictable monthly caps and per-second billing. That is exactly the shape we want here: small, inexpensive, and easy to leave running.

If you already have a VPS provider you like, you can adapt the commands. If you are following this guide because you want the cleanest path, start with DigitalOcean and move on.

DigitalOcean setup path

Start with the Droplet this guide is built around

Start with an Ubuntu LTS Basic Droplet, add your SSH key, and keep the plan small. Once the server is online, this guide turns it into a private Codex workspace.

Ubuntu LTS image

SSH keys

Basic Droplet

Create your DigitalOcean Droplet

Affiliate disclosure: this link may become a Build Lean SaaS affiliate or referral link. DigitalOcean stays the recommended path here because it keeps the first server setup simple and predictable.

What this should cost

For the first version, budget like this:

The server should be cheap enough that you can leave it running without turning it into a financial decision every month. If the workflow starts saving real time, resize later.

Definition of done

By the end of this post:

• You can SSH into the Droplet as a non-root user.
• Password login and root login are disabled.
• The firewall is on and only SSH is open.
• Node.js, npm, and Codex CLI work.
• ~/agent-workflows exists with places for repos, skills, state, and logs.
• Nothing agent-related is exposed to the public internet.

That is the handoff point for the next article. Once these are true, Codex can help prepare the server for Hermes without mixing setup, secrets, logs, and runtime state into one messy directory.

What this server needs

Start small:

• Ubuntu 24.04 LTS or 22.04 LTS.
• At least 1 GB RAM.
• 1 vCPU.
• 25 GB disk is plenty for the first pass.
• SSH key authentication.
• A persistent home directory for state files, OAuth tokens, logs, and scripts.

You can resize later. Starting small keeps the tutorial honest.

Create the Droplet

Create a new DigitalOcean Droplet with these defaults:

• Region near you.
• Ubuntu LTS image.
• Basic shared CPU.
• SSH key authentication.
• Backups optional for the first tutorial, but useful once a workflow matters.
• Monitoring enabled.

Do not expose extra ports yet. SSH is enough.

First login

From your local machine:

Update the server:

Install the basics:

Keep system updates boring

Enable unattended security upgrades:

This does not replace maintenance. It does reduce the chance that a tiny forgotten server sits unpatched for months.

Create a non-root user

Create a working user:

Copy your SSH key to the new user:

Open a second terminal and verify login before closing the root session:

From here on, use the agent user.

Harden SSH after the new user works

Only do this after ssh agent@YOUR_SERVER_IP works in a second terminal.

Open the SSH server config:

Use these settings when they are present:

Then validate and reload SSH:

Keep the working session open until the second login still works. Locking yourself out of a new VPS is easy and annoying.

Lock down the firewall

Allow SSH and enable the firewall:

This server does not need public web ports for the Codex-first setup. Keep it closed until a later tutorial has a specific reason to open a port.

Good first firewall posture:

• Allow SSH.
• Do not open HTTP or HTTPS yet.
• Do not expose raw agent ports.
• Add ports later only when a specific chat adapter, tunnel, or reverse proxy needs them.

What not to expose yet

At this stage, the VPS is an operator box, not a public app.

Do not expose:

• A raw Codex or Hermes control surface.
• A shell-command endpoint.
• OAuth token files or runtime state directories.
• Logs that may contain prompts, URLs, tokens, or task context.
• HTTP/HTTPS ports before a specific authenticated app needs them.

Add swap

Tiny VPS plans can run out of memory during installs. A small swap file makes the box less fragile.

Check it:

Install Node.js and npm

Use Node 20 or newer. One straightforward path is NodeSource:

The exact Node install method matters less than keeping it repeatable.

Install Codex CLI

OpenAI documents Codex CLI installation with npm:

Then authenticate:

Use ChatGPT sign-in if that is your normal workflow. Use API key auth if this server is meant to run more automation.

If you use an API key, keep it out of shell history and repo files. Put long-lived secrets in locked-down env files later, not inline commands you will forget about.

Start with read-only mode

Before letting an agent change anything, make it inspect the server.

That pattern is important. The first job is not to ask Codex to install everything blindly. The first job is to let it inspect the environment and explain what it sees.

Create a workspace folder

Create a place for agent workflows:

This folder can hold cloned repos, installed skills, state files, and scripts.

For example:

Do not scatter OAuth tokens and cron state across random paths. Future-you will hate that.

Use this split:

• repos/ for checked-out code.
• skills/ for installable Build Lean SaaS skills.
• state/ for OAuth tokens, processed IDs, and runtime state.
• logs/ for workflow logs you may need to debug later.

Cron, systemd, and persistence

For one daily script, cron is fine.

For a long-running agent or chat adapter, use systemd.

The dividing line is simple:

Whatever you choose, keep state on persistent disk. The X bookmark workflow is only trustworthy if the OAuth refresh token and processed tweet IDs survive reboots.

Back up the small things

You do not need a complex backup system for the first pass.

You do need to know what would hurt to lose:

• ~/agent-workflows/state
• ~/agent-workflows/hermes/config
• ~/agent-workflows/hermes/state
• Any manually installed skills or scripts you have not committed to Git.

Provider snapshots are enough for a starter workflow. Once the server starts handling customer or revenue-related work, treat backups as part of the product.

Why this comes before the X bookmark bot

The X bookmark capture script stores local state:

• OAuth refresh token data.
• Processed tweet IDs.
• Linear issue IDs and URLs.

That is fine for a personal automation, but only if the machine is stable. A VPS gives you the filesystem and scheduler that a laptop does not.

Once this box exists, the X bookmark tutorial becomes much more realistic:

• Install the skill.
• Authorize X once.
• Test a dry run.
• Add cron.
• Let the server run it daily.

What comes after this foundation

This box is the base layer for the rest of the Build Lean SaaS agent workflow series.

Next, we will use Codex planning mode to prepare the server for Hermes. After that, we will install Hermes/OpenClaw, connect it to a private Discord channel, and only then add the X bookmark workflow. That way the bot has somewhere to report what it finds before it starts creating work.

That is the system:

The point is not to build a giant platform. The point is to create one reliable place where small useful workflows can live.

Supported implementation

Want help setting this up with a second set of eyes?

Use the guide yourself, or pair with DevelopJoy when you want the VPS, Codex, skills, cron, and future Hermes setup wired together in your actual workspace.

Build it with us

Pair-programming lab

$100/mo

Monthly pairing session

Agent workspace setup help

PR review and workflow debugging

Start pair programming

Have us build it

Done-for-you focus sprint

Starts at $500/mo

Four monthly development hours

One focused workflow lane

Two alignment meetings + revision pass

Explore done-for-you setup

Prefer DIY? Continue the setup series.

What comes next

The next article uses Codex planning mode to prepare this VPS for Hermes without guessing at the exact Hermes install path too early.

Read next:

• Use Codex to Prepare a VPS for Hermes
• Connect Hermes to Discord

References

• DigitalOcean Droplet pricing
• DigitalOcean affiliate program
• Codex CLI docs
• Codex sandboxing docs