Hermes Agent Cron Jobs in Plain English: Set Up Automated GitHub Backups with a Single Sentence
Hermes Agent lets you schedule cron jobs in plain English. Type 'every night at 12am, push changes to GitHub' and it creates the skill and cron automatically.
Type One Sentence. Get a Cron Job.
Hermes Agent has 140,000 GitHub stars and an MIT license, but the feature that keeps surprising people isn’t the self-improving skill system or the voice notes — it’s this: you type “every night at 12am central time, push changes to this GitHub repo” and Hermes creates both the skill and the cron job automatically. No crontab syntax. No scheduler configuration. No YAML. One sentence.
That’s the specific thing worth understanding here. Not the general idea that AI agents can do scheduling, but the concrete mechanics of how Hermes handles it — and why the GitHub backup case is the right first cron to set up.
The Concrete Setup That Produces a Working Cron
Here’s what actually happens when you send that message to Hermes through Telegram.
Hermes receives the natural language request. It searches its available skills — there are 91 built-in on a fresh install, and Hermes already ships with GitHub repo management and GitHub auth skills. It runs some terminal commands to check the environment. It invokes cron job create tooling. Then it runs cron job list to verify the job registered. Finally, it updates memory.md with a note about the new automation.
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
The output you get back isn’t just a confirmation. Hermes explains what it did: it noticed the Docker container runs in UTC, so rather than hardcoding a UTC offset that would break during daylight saving transitions, it set the cron to run hourly and self-check against central time. That’s the kind of decision a competent engineer would make. Hermes made it without being asked.
The resulting skill is called nightly-github-sync. It lives as a skill.md file with YAML front matter that tells Hermes when to invoke it. The cron session that fires at midnight is isolated — it doesn’t inherit any context from your current conversation. It runs the skill, pushes the changes, and sends the result back to your Telegram chat.
Before any of this works, you need to give Hermes your GitHub token. The right way to do this is not to paste it into the chat. Instead, SSH into your VPS terminal and run:
hermes config set GITHUB_TOKEN [your-token]This writes the token to /opt/data.env inside the Docker container without it ever appearing in conversation history. If you’re using OpenAI Codex OAuth — which lets you power Hermes through your existing $20/month ChatGPT subscription instead of separate API billing — that conversation history is going through OpenAI servers. Rotating a leaked token is easy; not leaking it is easier.
When you generate the GitHub token itself, use a fine-grained personal access token scoped to the specific repo with contents read/write. A classic token with full repo scope works too, but the fine-grained approach limits blast radius if something goes wrong.
Why the Backup Cron Is the Right First Automation
The GitHub sync cron isn’t just a convenient demo. It’s structurally important.
Hermes stores everything that matters — user.md, memory.md, soul.md, all your skills — as markdown files inside a Docker container on a VPS. If that container gets corrupted, or you accidentally nuke it while debugging something, you lose all of it. The nightly GitHub push is your insurance policy. A new Hermes instance can sync from that repo and pick up where the old one left off.
This is also why the Docker container approach (via Hostinger’s one-click install) makes more sense than running Hermes at the VPS root level. Each container gets its own .env file, its own API keys, its own memory. When you eventually spin up a second Hermes — a finance agent, a marketing agent, whatever — they won’t share credentials. The GitHub backup cron for each agent pushes to its own private repo. Clean separation.
The KVM 2 plan on Hostinger is the recommended starting point. It gives you enough CPU and RAM to run multiple containers without immediately hitting resource limits, and you can scale up later if needed. The one-click Docker install for Hermes is available directly in the Hostinger dashboard under the Docker manager — search for Hermes, set your admin username and password, deploy.
For anyone building more complex agent infrastructure, running multi-agent systems with heartbeat scheduling follows similar patterns — isolated agents, scheduled tasks, and a clear separation of concerns between what each agent owns.
What the Cron System Actually Enables
The GitHub backup is the simplest possible cron. The system handles considerably more.
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
Hermes can run a daily AI news briefing and post it to a community. It can monitor YouTube comments — with transcript access and knowledge about the channel owner — and respond autonomously. It can do morning business summaries, server health checks, research reports, and follow-up reminders. All of these were set up through natural language, not configuration files.
The scheduling syntax is flexible. You can say “every morning at 6am, do X.” You can say “for the next 12 hours, check comments every 10 minutes, then kill the cron.” You can chain cron outputs — the context_from flag passes one job’s output as input to another. The work_dir flag runs tools from a specific project folder. There’s even a no_agent flag for cases where you just want a script to run without the full agentic loop.
One constraint worth knowing: cron sessions cannot recursively create more cron jobs. The prompts need to be self-contained. This is a deliberate safety decision, not a limitation to work around.
The mental model that helps here is the distinction between Claude Code and Hermes. Claude Code is a terminal-based coding assistant — you sit at your desk, you drive it, you manage context explicitly. Hermes is what you reach for when you’re on your phone, on a walk, and you want to spin up an automation or check in on running tasks. The cron system is central to that use case: you set something up once in natural language, and it runs while you’re doing other things. For more on how Claude Code handles remote control scenarios, Claude Code Dispatch covers the Telegram-based approach in detail.
The Non-Obvious Part: What Hermes Does After the Cron Fires
Most scheduling tools just run the job and log the result. Hermes does something more interesting.
After the nightly GitHub sync runs, Hermes updates memory.md. It records that the sync is active, what repo it’s pointing to, what branch it’s using. If the sync fails — say, because a token expired — Hermes will surface that in your next Telegram conversation. It doesn’t silently fail and leave you wondering why your repo hasn’t been updated in three weeks.
This connects to the broader self-improving loop. Skills get updated based on feedback. Memory gets updated based on outcomes. The soul file — which shapes personality and tone — evolves over time. The cron system isn’t separate from this loop; it feeds into it. A cron that runs nightly and occasionally fails is a cron that Hermes will eventually ask you about, suggest improvements to, or patch on its own if you’ve given it permission.
The skills hub at the Hermes documentation site lists 520+ community skills, with 16 official Anthropic skills available. If you want your GitHub sync cron to do more than just push changes — say, generate a commit summary, or post a status update to Slack — you can pull in additional skills and chain them. The YAML front matter in each skill.md file tells Hermes when to invoke the skill, so adding a new step to the nightly sync is a matter of updating that front matter and describing the new behavior.
For teams thinking about how to structure multiple agents with different scheduling needs, OpenClaw best practices after 200+ hours of use covers similar territory around crons, sub-agents, and keeping things from getting tangled.
Managing Multiple Agents Without Losing Track
Once you have one Hermes running with a nightly backup cron, the temptation is to spin up more. A marketing Hermes. A finance Hermes. A research Hermes. The Docker container model handles this cleanly — each agent in its own container, its own .env, its own GitHub repo.
The organizational problem is different. Which container is which? What’s the IP? What’s the admin password? What skills does each one have?
The approach that works: create a Claude Code project specifically for managing your VPS agents. A folder per agent, each with an .env file containing the admin credentials, the container name, the GitHub repo URL, and notes about what skills and crons are active. When something breaks — and something will break — you open that project, give Claude Code the relevant context, and ask it to help you debug. Claude Code can SSH into the VPS, inspect the container, and fix things. Hermes can help too, but having a second agent that can reach into Hermes’s environment is useful redundancy.
This is also where thinking about agent permissions matters. Each agent should have API keys scoped to exactly what it needs. The marketing agent doesn’t need read access to your accounting software. The finance agent doesn’t need write access to your social media accounts. Treat each agent like a new employee: give them the credentials for their job, not your master password.
For teams building more elaborate agent hierarchies, AI agents for personal productivity covers the decision framework for when to split work across agents versus keeping it in one.
The Broader Pattern: Automation as Conversation
What Hermes’s cron system demonstrates is that the interface for scheduling automation doesn’t have to be crontab syntax or a drag-and-drop scheduler. It can be a sentence.
This matters because the bottleneck in most automation setups isn’t the technical capability — it’s the friction of expressing what you want in a format the system understands. Crontab syntax (0 0 * * *) is learnable, but it’s not how you think about “every night at midnight.” Natural language scheduling removes that translation step.
The tradeoff is visibility. When you’re in the Hermes CLI rather than Telegram, you can see your context window, manage compaction explicitly, and run slash commands. In Telegram, the session management is more opaque — Hermes handles auto-compaction under the hood, and you have less control over when context resets. For cron jobs, this doesn’t matter much. For complex coding sessions, it does. That’s why Hermes and Claude Code aren’t competing tools — they’re optimized for different modes of work.
If you’re thinking about how to build scheduled automations without writing the orchestration code yourself, MindStudio offers a no-code path: 200+ models, 1,000+ integrations, and a visual builder for chaining agents and workflows, which covers a lot of the same territory for teams that don’t want to manage VPS infrastructure.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
The GitHub backup cron is a good first automation not because it’s impressive, but because it’s load-bearing. Everything else you build with Hermes — the skills, the memory, the soul file, the more complex crons — lives in that Docker container. The nightly push to a private repo means you can always start over without starting from scratch.
One sentence. One cron. Everything backed up. That’s the right place to start.
For teams thinking about the full architecture of what Hermes is doing under the hood — how memory, skills, soul, and crons fit together — the five-pillar breakdown of Hermes Agent’s architecture covers the design decisions in more depth. And if you’re evaluating whether to build your own skill-based agent infrastructure or use a compiled spec approach, Remy takes a different angle: you write an annotated markdown spec and it compiles into a complete TypeScript stack — backend, database, auth, and deployment — treating the spec as the source of truth rather than the generated code.
The nightly GitHub sync is running. The repo is private. The token is in the .env, not the chat history. That’s a solid foundation.
