You message it from your phone like a person, and it reads your files, uses tools, plans tasks on its own and carries them out every night without you. This is Hermes — an AI assistant you stand up on your own server and run like a new hire. In this course I'll take you from an empty cloud machine to a working assistant wired up to chat, with a first automation under its belt. Along the way I'll explain the five concepts everything rests on, walk you through installation and configuration, and at the end I'll tell you how to maintain it safely. Start with the vocabulary, because without it the rest blurs together.
What Hermes is and why you stand it up yourself
Let me start with a single word, because everything else bounces off it. An agent is a program built on an AI model that doesn't just answer questions but runs steps on its own: it reads files, reaches for tools, takes actions. Hermes is the wrapper that turns a raw AI model into exactly that kind of agent. It's an open-source project — anyone can download it and look it over — and one of the faster-growing of its kind on GitHub. The name "Hermes" is simply the name of the tool; you'll give your own instance its own character later and treat it like a member of the team, not a chat window.
The most important thing I want you to remember: Hermes runs on your own infrastructure. That could be a Mac Mini sitting on your desk, your laptop, or — and this is the option I recommend to start — a rented cloud server. You steer it through a messenger. I'll show you with Telegram, but it could just as well be Discord, Slack or WhatsApp; that's your remote control for the assistant, not its heart.
Before you begin, one distinction that can be confusing at first. You may know Claude Code — the tool in which the Claude model works on code and operational tasks, sitting in a terminal next to your project. You sit down at it and steer it: it's the "at the desk" tool. Hermes is "on the move." You fire something off from your phone on a walk, the assistant wakes up at once and replies in chat. In my view this isn't an either-or choice: Hermes doesn't replace Claude Code, it just takes a different place in your day. I use both at the same time myself and I'd recommend it to you too — but if you're only just starting, keep that in the back of your mind and stand up one simple stack first.
The five pillars Hermes stands on
This is the most important bit of theory, and please don't skip it. Without these five concepts, the whole installation that follows will be a jumble of commands to you; with them, it all clicks.
Memory. The assistant wakes up with no memory every time — it doesn't remember the previous conversation off the top of its head. Its memory is the files it writes itself and loads at the start of every session. The two most important are a file about you (who you are, how you work, what you can't stand) and a context file (your projects, your company, your surroundings). The good news: Hermes adds facts to them on its own as it works. The bad: don't go completely passive about it. When something important comes up, tell it outright: "save this to memory" or "never do this again, put it in the file about me."
Skills. These are ready-made instructions for "how to do a given thing well." Picture a cooking recipe. Going from memory, the pancakes come out burned one time, pale the next; with a recipe, the same every time. Each skill is a separate file with a short description at the top — from that description the assistant knows when to use it, and it doesn't waste attention on the rest until it needs it. Hermes has plenty of them right after installation, and you'll add more from a public library that holds hundreds of ready-made skills from the community. And the thing I like best: if you do something often, Hermes will suggest on its own that you turn it into a skill.
Personality. A separate file that gives the assistant its tone: one is terse, another easygoing. It matters especially when other people come into contact with the assistant — that's when they feel its character. If your Hermes is, say, to reply to comments under your content, you can tell it to be "mildly sarcastic but not rude." This file changes over time too, as you adjust it.
Recurring automations. Here comes a word I want to make familiar to you: cron. It's simply a scheduled, repeating task. For me it's Hermes's biggest advantage. You tell it in a plain sentence "every day at 6 a.m. do such and such," and it sets it up itself. At the appointed time it wakes up in a fresh, separate session — it doesn't drag your current conversation along — carries out the task and sends the result back to chat. That's it. No clicking through panels.
The self-improvement loop. It ties the previous four pillars together. You do the work, you correct the assistant, it saves the lessons to memory and turns repeating steps into new skills — and round it goes. The more you use it, the better it understands you. Just keep a level head: automatically doesn't mean magically. This loop works best when you actively correct it and have it save the lessons, rather than leaving it to its own devices.
Standing up a cloud server
Now the work. The assistant will live on a VPS — short for "virtual private server," a rented cloud computer that runs nonstop and that you manage remotely. With some providers Hermes has a "one-click" install, so you don't have to build anything by hand, but you'll repeat the whole procedure anywhere.
You have two decisions to make. First: how much power the server should have. You pick a plan, which sets how much processor and memory you get. To start, a mid-range option is comfortably enough — you can scale it up later with one click, so don't overpay up front. When you buy, you also choose the server's location and set an administrator password; save it somewhere safe right away.
The second decision: where the assistant should live. You have two routes. You can stand Hermes up directly on the server (the phrase is "on root," meaning at the machine's top level). Or — and this is the option I recommend — place it in a container. A container is an isolated "box" inside the server, where Hermes has its own files and its own keys, separated from the rest. I choose this route for two reasons: it's the simplest (usually it's the one-click install) and it lets you stand up several separate assistants alongside it later without them getting in each other's way. Think of the server as an office building and each container as a separate room with its own key.
And here I'll give you a piece of advice I consider one of the more important in the whole course, though at first glance it looks like overkill. In parallel, set up a separate project in Claude Code to manage your servers. Keep your passwords in it, the server addresses, and a short note on how each assistant is configured — which container it sits in, where it keeps its keys. The reason is purely practical. Most of us don't feel like experts on servers and commands, and that's completely normal. If something breaks or you forget a password, you have one tidy place and a second tool to help you undo it. I come back to a project like this more often than I expected.
Configuring the model, chat and first conversations
After installation the assistant runs a short onboarding and asks a few questions. You point it at two things.
The first is the model provider — the "brain" Hermes uses. From the list of options, pick the one that lets you connect your existing ChatGPT subscription, rather than billing separately for every request. That's usually the cheapest sensible option, unless you run a model locally on your own hardware. Once you've chosen, you click a link, log into your account, copy a short code back into the terminal, and that's it — the assistant has access to the brain. Finally you pick the specific model.
The second is the conversation channel. Here you set up your own bot on Telegram. You do it within the messenger itself: you message the built-in "BotFather," ask for a new bot, give it a name, and it hands you a token — a string that confirms a given program has the right to act on your behalf, something like a password for applications. You paste that token to the assistant. For safety you also specify who is even allowed to message the assistant: you supply your user ID (you'll get it by messaging a bot called "userinfobot" on Telegram), so that at first only you can talk to it.
And now the most important lesson of this stage — it comes back throughout the course, so remember it well. When you wire up Telegram, it's easy to hit a situation where you send the first "hi" and nothing comes back. Silence. The temptation is to dig into the code and panic. Don't. Go back to Hermes in the terminal and describe the problem in a plain sentence: "I sent a message on Telegram and I'm getting nothing back." The assistant will look under the hood itself, find that the service was stopped, start it and report that it's ready. Try again — this time you see it typing, and you get a reply. The takeaway is this: you don't have to understand how everything works under the hood — you have to be able to describe clearly what you see and what isn't working. That takes a huge amount of the stress out of the whole exercise.
Once the connection is working, give the assistant five to ten minutes and simply tell it about yourself: what your goals are, what you're working on, who's on your team, which processes you want to hand off to it over time. In the background it starts building its memory files and getting to know you better. This isn't wasted time — it's the foundation the rest will stand on.
Your first skill and first cron: a nightly backup on GitHub
I won't stop at getting it running — I'll show you the first real task, because it brings several pillars together at once and explains them best. Before you trust the assistant with anything about yourself, have it connect to a private repository on GitHub. GitHub is a cloud place for storing files and projects; think of it as a shared drive. The point is single: if your server breaks, the assistant's entire "memory" — files, skills, context — is safely set aside outside it. You stand up a new Hermes from scratch, connect that repository, and nothing is lost.
Along the way comes a lesson about access keys that I want to drill into your head once and for all. You don't paste the GitHub token into the body of the conversation. When you do, the key stays in the chat history and ends up on the model provider's servers. Instead, you enter it with a separate command into a separate configuration file inside the container (that file is usually called .env). It's the same rule you apply to every key, without exception. And if you get it wrong — say you generate a token with permissions that are too narrow and it turns out the assistant can't create the repository — nothing terrible happens. You have Hermes show you the command to open that file, you delete the old key, paste in a new one and carry on. Stumbles here are part of normal work, not a disaster; I rack them up myself, and you will too.
Finally you wrap it in a cron, and here the magic of the first pillar happens in practice. In one sentence you ask: "every night at midnight, send a backup to this repository." The assistant builds a skill around it and sets up the automation on its own. What's more — it takes care of a detail that's easy to forget: the server usually runs on universal time (UTC), so Hermes arranges the task to land at midnight in your time zone despite clock changes. And that's all: one instruction in plain language turned into a durable skill and a repeating habit. That's exactly what the loop I mentioned at the start looks like.
Security and scaling: one assistant or several
Two threads are left that are worth knowing before the assistant gets access to your data and before you start multiplying instances.
I boil security down to a single rule: treat the assistant like a new hire. Give it its own accounts, not yours — its own email address, its own logins to tools. Hand out narrowly scoped keys, only what it really needs for its role. If it's going to spend money, give it a separate, named key, so you can see exactly how much it costs. The control question to keep asking yourself: on day one, would you give a new hire your card details and access to everything? Exactly. I'm not a security specialist, and I'd advise you too not to play the expert — consider a firewall on the server, and for the configuration itself, let both Hermes and Claude Code help you. You can even have the assistant run a short check every night on whether everything is locked down as it should be.
Scaling is the question: one assistant or several. I'd advise against rushing. First squeeze everything out of one, because you're still learning how skills and memory work anyway. Only set up a new one when the task really calls for it. Run a simple checklist in your head: does this new role need its own keys or tools? Its own, separate long-term memory? Is it steady, repeating work for a different audience? If you answer "yes" even once, split the roles into separate instances. If it's "no" across the board, leave it in one. The wrong path is one "overloaded" assistant with all the keys and dozens of skills at once — high risk and a mess, like keeping all your eggs in one basket. The right path is a clean split, e.g. a separate Hermes for marketing and a separate one for finance, each in its own container and with its own keys. And because everything is saved in files, moving skills and automations to a new assistant is dead simple.
What to take away from this
The whole course has a clear spine: from an empty server, through the five pillars and the installation, to the assistant's first working habit and the rules for maintaining it. The strongest conclusion, though, isn't technical. You never "finish configuring" Hermes — it's a collaborator that you guide and keep teaching. Three simple reflexes you maintain it with: when it gets the same thing wrong twice, correct it on the spot and have it update the relevant skill or memory. When it talks too much or in the wrong tone, have it fix the personality file. And when it starts behaving strangely, look at its memory first — out-of-date memory is the most common cause of strange behavior.
And one honest caveat to close on, because it's the thing that most often decides success or failure: someone else's way of using it isn't your way of using it. Before you build your own assistant, sit down and answer one question for yourself — which specific repetitive chore do you want taken off your plate. That, not a flashy demo, will tell you whether it's worth it at all and where to start. Pick that one thing and set up your first cron for it specifically.