Building an Always-Online Personal AI Agent on an Oracle Cloud VPS with Hermes, GitHub Copilot, and Telegram
- Get link
- X
- Other Apps
Building an Always-Online Personal AI Agent on an Oracle Cloud VPS with Hermes, GitHub Copilot, and Telegram
What if you could have your own AI assistant running 24/7 on a server, accessible from anywhere, without keeping your laptop running?
Imagine sending a message to a Telegram bot while commuting, asking it to research a technical topic, write a blog post, investigate an issue, or execute a task on your server.
A few moments later, your personal AI agent responds.
It can also run scheduled tasks, work independently, and continue operating even when your computer is turned off.
That was the idea behind my latest experiment: building an always-online personal AI agent using an Oracle Cloud VPS, Hermes Agent, GitHub Copilot, and Telegram.
This article documents the complete setup journey, including the installation, integration, configuration, and some problems encountered along the way.
1. The Architecture
The goal was to build a personal AI assistant with four main components:
Oracle Cloud VPS: Provides the always-online computing environment.
Hermes Agent: Acts as the autonomous agent framework, managing conversations, tools, tasks, and sessions.
GitHub Copilot ACP: Provides access to AI models through GitHub Copilot.
Telegram: Provides a convenient mobile interface for communicating with the agent.
The architecture looks like this:
My Phone / Telegram
|
|
Telegram Bot
|
|
Hermes Gateway
|
|
Hermes Agent
|
|
GitHub Copilot ACP
|
|
GitHub Copilot
AI Models
|
|
Oracle Cloud VPS
(Always Running)
|
Scheduled Tasks
Background Jobs
Local Files
Server ToolsThe important distinction is that Telegram is just the communication interface. Hermes is the actual agent running on the VPS, while GitHub Copilot provides the AI capabilities.
This separation makes the architecture flexible. The messaging interface, agent framework, and AI provider can evolve independently.
2. Our VPS Environment
I already had an Oracle Cloud Always Free eligible ARM64 instance available.
The environment:
| Component | Configuration |
|---|---|
| Cloud Provider | Oracle Cloud |
| Instance Shape | VM.Standard.A1.Flex |
| Architecture | ARM64 / AArch64 |
| CPU | 2 OCPUs |
| Memory | 12 GB |
| Operating System | Oracle Linux 9 |
| Login User | opc |
| Storage | 50 GB |
| Access | SSH through Cloudflare Tunnel |
One advantage of using an existing VPS is that we don't need another computer running at home.
The server is independent of my Mac, and I can access it from my Android phone.
I had also configured Cloudflare Tunnel for SSH access, so I didn't need to expose an SSH port directly to the public internet.
If you want to learn how to build this foundation, see my earlier article:
How to SSH into an Oracle Cloud VM Without a Public IP Using Cloud Shell and Cloudflare
3. Installing Hermes Agent
The first step was installing Hermes Agent on Oracle Linux.
Hermes is an open-source autonomous AI agent developed by Nous Research.
Unlike a simple chat interface, Hermes provides an agent environment with capabilities such as:
Persistent conversation sessions.
Tool execution.
Scheduled tasks.
Background automation.
Gateway integrations.
Multiple AI provider integrations.
The official installation command is:
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bashDuring the installation, we encountered our first issue.
The installer complained that Git was missing.
Since this is a relatively minimal Oracle Linux installation, we needed to install the prerequisite first:
sudo dnf install -y gitVerify:
git --versionThen rerun the Hermes installer.
After installation, Hermes was available from the user's local executable directory.
One useful lesson: when installing developer tools on a minimal ARM64 Linux server, check the system prerequisites before troubleshooting the application itself.
4. Using GitHub Copilot as the AI Provider
The next challenge was choosing an AI provider.
Instead of setting up a separate paid API account, I wanted to use my existing GitHub Copilot access.
Hermes supports different provider integrations, and we chose the Agent Client Protocol (ACP) integration for GitHub Copilot.
ACP provides a standardized way for an application to communicate with an AI coding agent.
The resulting integration looks like this:
Hermes Agent
|
|
ACP Client
|
|
GitHub Copilot ACP
|
|
GitHub Copilot ModelsThis is different from simply using an API key to call an LLM endpoint.
Hermes communicates with the Copilot agent through ACP, allowing it to use the agent's capabilities through the protocol.
Installing GitHub Copilot
We initially explored installing the GitHub Copilot CLI through npm.
However, the npm installation command we first tried was not valid for the intended setup.
We then moved to the official GitHub Copilot installer.
curl -fsSL https://gh.io/copilot-install | bashOn Linux ARM64, executable compatibility is particularly important.
During troubleshooting, we found that multiple Copilot executables could exist in different locations. A binary installed through npm could conflict with the standalone installation.
Useful diagnostic commands:
uname -m
type -a copilot
which -a copilot
file ~/.local/bin/copilotThe official installer placed the executable under:
~/.local/bin/copilotIf necessary, prioritize this directory in your PATH:
export PATH="$HOME/.local/bin:$PATH"And persist it:
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrcConfiguring Copilot ACP in Hermes
With Copilot installed, the next step was configuring Hermes to use Copilot ACP as its AI provider.
The important point is that installing Copilot CLI and configuring Hermes are two separate steps.
We needed to:
Make the Copilot executable available to Hermes.
Configure the ACP provider in Hermes.
Complete the GitHub authentication process.
Select the Copilot provider/model in Hermes.
Verify that Hermes could successfully send requests and receive responses.
GitHub authentication can be checked using the available Copilot or GitHub CLI authentication mechanisms.
For example:
gh auth statusThe actual authentication method and available models depend on your GitHub account and Copilot entitlement.
One advantage of this approach is that we can leverage existing Copilot access instead of immediately introducing another standalone API billing account.
However, Copilot usage limits still apply. We encountered rate limiting during our experiments, so an always-online agent does not necessarily mean unlimited AI usage.
5. Setting Up Telegram as the Remote Interface
This was probably the most exciting part of the project.
I wanted to manage the agent from my phone without SSH-ing into the VPS every time.
Telegram provides a convenient solution.
Creating a Telegram Bot
Open Telegram and search for:
@BotFather
Start a conversation and execute:
/newbotFollow the instructions to choose a bot name and username.
BotFather will generate a bot token.
Keep this token private. Anyone who obtains it may be able to control your bot.
We also needed our Telegram user ID so Hermes could restrict access to the authorized user.
This is important because we don't want a publicly accessible bot executing commands for strangers.
Configuring Hermes Gateway
Next, we configured the Hermes Gateway integration.
The Gateway acts as the communication layer between Telegram and the running Hermes agent.
Conceptually:
Telegram Message
|
v
Telegram Bot API
|
v
Hermes Gateway
|
v
Hermes Session
|
v
AI Provider (Copilot ACP)
|
v
Agent Response
|
v
TelegramAfter configuring the Telegram bot token and access permissions, we started the Gateway.
At this point, the bot became the remote interface to our VPS-based AI agent.
Pairing and Starting a Session
One interesting detail we encountered was that configuring the Telegram integration did not automatically mean an active agent session was ready.
Initially, we couldn't see a new pairing.
We had to start a new session from Telegram and complete the pairing process.
After that, communication started working.
We also encountered this message:
no reply: auto didn't produce a reply this time,
even after retries.This was a useful reminder that a functioning Telegram connection doesn't necessarily mean the AI provider is responding successfully.
There are multiple components involved:
Telegram connectivity.
Gateway availability.
Agent session state.
Provider authentication.
Model availability and rate limits.
When troubleshooting, check each layer independently rather than assuming every problem comes from Telegram.
6. What Can We Actually Do with This Agent?
Now we have something much more interesting than a Telegram chatbot.
The agent lives on the VPS, and Telegram provides a convenient way to interact with it.
Some potential use cases include:
Remote server management
From my phone, I can communicate with the agent and ask it to:
Check server resource utilization.
Inspect application logs.
Investigate service failures.
Review disk usage.
Execute maintenance commands.
Diagnose deployment problems.
Instead of opening an SSH client and manually executing every command, I can delegate an investigation to the agent.
Independent research and writing
This is particularly interesting for my QZ-L project.
I already have an independent AI research and writing workflow.
The agent can be used to:
Discover interesting technology topics.
Research new frameworks and tools.
Analyze technical developments.
Generate technical blog drafts.
Review existing articles.
Help maintain project documentation.
The objective is to reduce the amount of manual work required to maintain and grow a personal technology project.
Scheduled tasks
Hermes also supports scheduled and recurring work.
This opens up another interesting possibility.
For example:
Every morning:
1. Review interesting technology developments.
2. Research a selected topic.
3. Prepare a summary.
4. Generate a draft article.
5. Notify me through Telegram.The agent can perform work independently rather than waiting for me to open a chat.
For background jobs, we can also design workflows that send their results or notifications to the Telegram bot.
Remote task assignment
Perhaps the most useful feature is the ability to assign work remotely.
Imagine sending:
Check the latest application logs.
Find out why the scheduled job failed.
Investigate the error and suggest a fix.The agent can investigate the issue on the VPS and return its findings through Telegram.
I don't need to be sitting in front of my Mac.
7. Why This Is Different from a Normal AI Chatbot
A traditional chatbot generally waits for a message and returns a response.
An autonomous agent has a different responsibility.
| Traditional chatbot | Personal AI agent |
|---|---|
| Responds to questions | Executes delegated tasks |
| Usually request-driven | Can perform scheduled work |
| Limited application context | Can work with local files and tools |
| Chat-centric | Task-centric |
| Depends on an active conversation | Can operate in the background |
Of course, an agent is only as capable as its configured tools, permissions, provider, and available resources.
It also needs sensible security restrictions. I would not recommend giving an internet-accessible Telegram bot unrestricted root access to a server.
For a personal setup, access control, protected credentials, and careful command permissions are essential.
8. What I Want to Build Next
Getting Hermes running with Copilot ACP and Telegram is just the foundation.
There are several directions I want to explore.
1. A personal DevOps assistant
Let the agent monitor services, inspect logs, identify problems, and notify me when something needs attention.
2. An autonomous research assistant
Have it independently discover topics, conduct research, and prepare technical articles for QZ-L.
3. A Telegram-based task management interface
Use Telegram as the place where I submit tasks, review progress, receive results, and decide what to do next.
4. Multiple agents and specialized workflows
Eventually, I would like to experiment with different specialized agents for research, development, server maintenance, and content creation.
5. More efficient AI provider management
Copilot usage limits are something to consider. I want to experiment with different providers and fallback strategies so that scheduled work doesn't simply stop when one provider becomes unavailable.
Conclusion
What started as an experiment with a free Oracle Cloud VPS has evolved into something much more interesting.
We now have:
An ARM64 Linux server running independently.
Hermes Agent as the autonomous agent framework.
GitHub Copilot ACP as the AI provider integration.
Telegram as the remote communication interface.
The foundation for scheduled and background tasks.
The most interesting part is not the technology itself. It is the change in how we interact with our own infrastructure.
Instead of logging into a server every time we need something done, we can increasingly delegate work to an AI agent and communicate with it through a simple Telegram conversation.
Our personal AI assistant is no longer tied to a laptop or a browser tab.
It lives on a server, stays available, and is accessible from anywhere.
And this is only the beginning.
❤️ Support This Blog
If this post helped you, you can support my writing with a small donation. Thank you for reading.
- Get link
- X
- Other Apps

Comments
Post a Comment