Un agent Hermes pot mantenir webs en un VPS de 6 dòlars?

So when you start with AI coding tools and you start making projects and want to actually deploy websites and web apps. If you're using Cloud or Codex, they'll often suggest you use, you know, Superbase or Railway or Vercel. And when I started out those were the different platforms that I was using and they're all great for what they do and especially for beginners. But I've found a way to replace all of them run my web apps all on a small VPS with one Hermes agent maintaining. the app content and running my businesses. In this video, I'm going to show you what my setup is. I'll introduce some of my work flows, agent, to work flows that makes this possible. And then I'm actually going to demo deploying a new web app onto this same BPS with the same agent ready to run for me. So let's get started. And if you like this video, please consider supporting the channel by joining Team Garage. which will give you early access to videos or team garage max where you'll get exclusive videos each week as well as many other perks. I'd like to continue providing as much free, valuable content as possible, so it was better experiments on different hardware. So these memberships were really make it possible. So a few things to start what we're going to cover here is going to be kind of the usual stack and what it gives you. Then I'm going to show you the example of Asian Wikis. This is a real site. This is live.

at AsianWakeys.com you can check it out yourself. It's all free knowledge bases for your agents. You can check it out. You can join the wait list to request your own private knowledge base, but these are all free to use. So this has been the site that I have primarily been managing with this Hermes agent. So I'll show you some of the workflows that I have with it and how I keep all the information fresh. Make sure that I am able to fix any issues quickly and largely autonomously Then we're gonna look at a site that needs a database like agent Vicki's doesn't really need a database itself It's mostly just marked down files the game app that I'm going to be showing you actually needs one So that's where you would usually use super base But I'm gonna show you how to kind of replace it with this BPS and an agent So this is the usual stack And like I said, if you were by coding in the winter with Opus 4.5, it would usually like give you these options or couple others. And they offer a lot. I'm simplifying here, but for sales mainly for deployment of frontends railway, you can do managed postgres backups. A lot of apps that need back end will use railway and super base is used a lot for.

data bases, postgres to get off real-time row-level security storage. These are all good. I've all I've used them all. But running them as a stack can get a little bit expensive. And the reality is that having a BPS or any kind of server like that can replace these functionalities or at least the core functionalities. What they really give you is derisking and convenience, they're super convenient. So let's keep that in mind as we move forward. Okay, the site that needs nothing. Well, they need something, but this is Agent Wicke's once again. And it has no database, it has no built-set. It was specifically created and coded to be super agent friendly. And get is the database. There's no actual database, it's just get. Agent Wicke's is now, I think, we're up to a couple more Wicke's, but we have a 16 right now that are all public. And the Wicke's just a folder of Markdown files. I have them for Hermes Agent Hyperframes, comfy UI, a bunch of others. So this is how it was built out. The app, server renders Markdown from disk on every request. It keeps a search index, in memory that only rebuilds when the files actually change. So git push is the deploy. A pull on the server is instantly live. There's no restart, no rebuilding. So for a huge class of site, docs, blogs, wikis,

Marketing pages, stuff like this, get is your database, your CMS, and your deploy pipeline, all in one. You don't need an actual database. The database would have been answering a question, this site never really asks. So this site doesn't get its own server. It's a tenant on a box that already runs my Hermes agent. If you watched episode two of the Hermes agent masterclass, you saw me deploy a Hermes agent on a BPS. So that agent is running on a 25 gig storage, 1VCPU, 1 gig, uh, drop-let of VPS basically. And you can see he is hooked up here to Telegram, so I can communicate with him directly. And he's always on, obviously, the VPS is always running. I always have access to him through Telegram. I don't need to keep my PC or laptop open for the him to be working. Here's how the work space is designed. But everything lives under the CRB slash Asian Wikis directory, the app and one git clone per wiki. So you see here that if it ones I have, her name is ComfortUI. So Cadi was already on the box terminating TLS for the agent. So the site just added a V host. So agentwikis.com just reverse proxies to the local host and then Cadi auto provisions the search from there. It's auto TLS.

So how I communicate or have access to this is I use SSH simply using the IP and then it uses his name which is Admiral and just the root Hermes chat and you could see pulls up the normal Hermes chat you would see so this is all on the BPS that I have access here to work in Hermes I'm using GPT 5.5 but I can work with Hermes on the BPS and have direct access to the files in it if I want to edit the site or make any direct changes. Now we'll go into more of the security measures because I don't give them full reign of it. Only the access to the parts of the site that he needs. And getting to that point, we have this pipeline for a loop that the agent conducts. And this is how it maintains the actual content for the most part autonomously. And if you watched my video about how to build a multi-agent workflow. I'll put a card or a link in the corner of this one and go back and watch that if you haven't, but that's the main pipeline that I use. It is multi-agent, multi-profile, really. But that is the same pipeline that I adapted here. So there's a cron that fires where I have scout, I research agents checking for new releases, checking sources of anything's updated or the various wikis.

Like for example, if it was a Hermes Asian wiki, it would check if there's been any new versions released, any updates, any changes to the change logs, any major features, any community notes from there with D-Doop and then get rid of any duplicate entries and then do research about what's generally new and worth adding as a page or adding as content to an existing page. And once it has its plan, there's the one telegram gate and this goes to me. in Telegram and it'll be the same one, the same admiral here. It would just send me that update and if I prove, then we ingest the sources we lent and we committed written to get and then it would be live on the site within 15 minutes without any kind of restart and then this repeats every cycle right now. I have the monobiecly weekly chrome just because I have a lot and doing one of these loops can be quite costly in terms of tokens. But if you want to see the details of how I built this out, like I said, check out that video I did. But I'm going to show you a different loop, actually. So this is the demand loop. And I think this is a really nice feature of Asian reviews. And the goal is pretty simple. When I use, like these knowledge bases, or I'll release myself every time I ask a question, which is in the wiki itself. And my agent has to go and find the answer. Then I have it automatically.

kind of updating with whatever information the agent finds to fill in those gaps in the knowledge. So I wanted to try to recreate that and try to learn what agents are actually asking for without ever reading anyone's prompts and be the gaps back into the pipeline automatically so that my wikis here can become even more robust and really answer the questions that people are asking for. So agents largely search in agent wikis using an MCP server. So what hits the server is it is stilled query not the pump itself nothing like that no IP or any kind of identifying information Just a distilled query just simply is this topic in the wiki and then it also logs whether or not it was hit or miss whether or not the information was in the wiki itself or it wasn't and these are aggregates only not individual logs So there's no prompt stores like as there's no prompts being stored no IPs no identity So these kind of repeated misses are the authoring backlog. So they get turned into like scout format candidates, what you would actually research. And this is where you would get the research agents working. And this is basically the same setup as my existing knowledge base pipeline that you saw just using this data as the source instead of searching for new releases or whatever. And the rest of the loop is pretty much the same, right? It formulates a plan.

or possible changes, new entries, edits. There's a human gate for research, right? Page versus extend in a prove, and that's what I approve. And then it goes back into the other multi-agent pipeline where it writes the new entries, verifies everything, commits it, and then it'll be live. So this is really a critical element and it's kind of a differentiator between my knowledge bases and what somebody else might be able to create, and having an agent. Right in the VPS with direct access to all this information Nothing leaves the box all this happens within the VPS. I think that's a pretty good advantage and most importantly it doesn't require me except for this one little Telegram approval So let me show you this workflow because this is new you haven't seen this one yet. You can see it working in the background. This is in the T.Y. In Hermes and you can see what I got from the Telegram chat here. Um, KB intake past five live demand gaps. So we found five questions that agents had that metacrit area. So that means that these questions have been asked at least twice in the last seven days. So that's kind of the standard. So it's creating a five item files and 15 child cards to verify on the effect of pages in that route. So it's going to research here and I'll get updates right in my

my telegram here. Okay, so the Chrome hit and you can already see some updates in telegram that I'm receiving. All the work is happening autonomously without me. So I'm just getting updates for now. You can see KB intake here, first five live demand gaps. So these all scored 88 of 100 in advanced. And the way I have this setup is that it needs the same kind of topic or keywords have to be asked about. at least twice in the last week. So I found five so far. And now it's created five item files and 15 child cards. It's going to research, we'll start with intake card completes. So I'll get intermittent updates like this in Telegram about what it's doing. This is the compound board in the VPS agent. Receiver blocked for a lot of this stuff. This is in progress. Grouding this item. Okay, here we go. Trying to get messages here in Telegram. So it's blocked because this is the gate, right? This is where it's going to make a proposal for me. Messaging gateway web hook route rate limits. So these are the different questions that people would be asking, the different topics they're trying to find. It wasn't in the current webby, Ricky. So this is what changes. This is why ingested.

and planned writer constraints, do not touch the raw reply. So same thing as you've seen my other work was, I can just approve this, I think we'll approve it, sounds good. And then it will continue to do it. So this is just one human gate, the rest of the process, like you saw, this autonomous, it runs on the cron. I just need this. So I know that it's not writing something completely off, or that there's not some kind of issue with the model that it's making. terrible decisions. So we can look at what this is going to update. This is going to update the messaging gateway, MD, add the web hook route, rate limit answer. You see this is what it is right now. So we can check to see if there's anything about rate limits. You see I'm searching for rate. My great rate limit is one about here code expires after one hour and our rate limited. And then that's the word separate. So we'll see once this is fine, once it's updated, it'll be added to the actual site. This is the actual, this is an local one, this is actually on agentwikis.com. So keep that in mind until the end. And you can see while the others are still working, this did the verify lint on that one. The rate limits question. So Rand, a lint on it to check for conflicts. Make sure everything was verified.

Everything was written in the specified Markdown file and see all the different formatting and stuff. So this winter helps keep everything properly formatted and it's going through that so you can see now it's on the commit stage in the con-bomb and you can see here we got our final confirmation message that the knowledge base ingest committed. So this is just their clone version. This is just on their branch. I get to decide whether or not to merge this onto the main. So you can see we're getting the other proposals, but for this one that already passed, right? You still need to merge it onto the main, but you should check the dip or you can check it with a different version of this agent. Just to sanity check it just to make sure that there's nothing strange in there. But you could see easily where the files are and where it made the commit, so you can check them. And then last year you would just manually merge it onto the main and then it would pull it and update the site. So let's do that. Okay, you can see the rest of those new entries were committed and looking at the compound board. Things clear. A bunch of things in done. 22 tasks from that demand gap pipeline. You can kind of see the dips here, but you can check this manually yourself. So these are the two kind of human gates I have, the one when they originally make the proposal.

and then lastly, just seeing the dips and then merging it all myself. Now, as I game confidence in this system, I may make this autonomous as well, but I've only been running it for a little bit here. Sensation Wiccus has been live. So I'm still, I still want to be in the loop a little bit. And we are on this live site, just updated automatically. I didn't have to do anything. You can see, rate is now nine entries so that means that it did and here we go. Here it is the WebHook rate limit. So this was not there previously. Each WebHook route defaults the 30 request per minute using a fixed window. So this answers that question that somebody had about WebHooks. So this is kind of the self-evolving, self-repeatifying part of this project and these these wikis. But the key here was this workflow, having a agent on a VPS running this whole site automatically and autonomously for the most part maintaining updating, linting it and keeping all the information relevant and updated. So this is a good workflow, having everything run through the VPS, but there are places where you need to reach. And this is one of single box is an enough, when you need real off.

like password resets a wall. Failure mode, then you want to go to something more robust. If you have something that's can't lose or regulate a data, I mean I have my wikis backed up locally. I have them on GitHub. But if it's something that you really can't lose, needs to be regulated, then you're going to want to do a managed postgres, so maybe like a railway in that case. Global and viral traffic. You have more advanced options with Versel and Cloud Flare. You now deliverability self hosted SMTP lands in spam. You can use postmark or resend and then team velocity. This is obviously I'm just a solo proprietor here. So for something where you need more teams, you need preview deploy is something like Bracel and Railway is great. So yeah, the main one, but you need to get be careful obviously is off holding real credentials. So you want to avoid any kind of breach. and handle that in a more sensitive and safe way. Okay, so this was my agent that runs my web apps. In this first video, we just did the one that didn't require a database and I showed you the different loops that it has. How it autonomously maintains my site without verse L, so base real way or anything like that. Now part two, I'm going to do another video kind of an extension of this on the same topic.

Then we're going to go into the site that needs a database. And I talked a little bit about my game app at the beginning of this, but this is going to actually be a follow up video. This one's running a little bit long. And that one's going to take a lot of time as well. These I'm going to be actually deploying this game app on the same BPS you just saw on that. And that's going to be a little bit more involved because it actually needs a database. So look forward to that. Probably being next week. But that's going to be it for this one. Please leave a comment. Let me know your thoughts on this workflow. How you would like to adapt this to your own apps or own sites. I'll see you in the next video. Thank you for watching.