The rule of thumb:<\/strong> self-host your AI agent if you want to tinker; go managed if you just want it to run. Either way, the runtime lives on an always-on server, and the model lives wherever your first decision pointed you.<\/p>Decision 3: Where should your agent’s state live?<\/h2> State is everything your agent remembers and holds: conversation history, long-term memory, the files and notes you’ve given it, scheduled tasks, and the credentials that let it act on your behalf, such as API keys, bot tokens, and access to your email or calendar.<\/p>
It’s the hardest part to replace. You can swap a model in minutes and move a runtime in an afternoon, but lose your state, and you lose the agent you built.<\/p>
Think back to Bhawnani’s Discord mentor. What makes it useful isn’t the model behind it, but the notes, teaching approach, and videos he’s given it. That’s state, and it’s easy to overlook until it’s gone.<\/p>
Make it survive change<\/h3> Keep state on persistent storage outside the agent’s installation, such as a mounted Docker volume or a database, and in a format you can export. That way, a rebuild can’t wipe it, and moving to another server or provider doesn’t mean starting over.<\/p>
Know who backs it up<\/h3> On a self-managed VPS, backups are your job unless your plan includes them. Managed options like Hostinger’s managed OpenClaw handle them for you, but check how often they run and how long they’re kept. Either way, test a restore at least once. A backup you’ve never restored is only a hope.<\/p>
Keep credentials apart from the model<\/h3> Your agent holds keys that can spend your money or act in your name. Store them on the server that runs your runtime, in environment variables or a secrets manager, and give each key only the permissions it needs. Never put them in prompts, memory, or shared config files: anything the agent sends the model can read, and if you use an API, the provider can too.<\/p>
Don’t keep state on temporary compute<\/h3> Treat a rented GPU as disposable. It’s built for compute, not as the long-term home for your agent’s memory. Hostinger GPU instances, for example, have no automated backups, and an instance is destroyed if your credit balance reaches zero. The pattern that works is to keep state on your VPS, spin up a GPU instance when you need it, send the results back, and destroy it. That way, losing the instance costs you nothing beyond compute time.<\/p>
The rule of thumb:<\/strong> for a personal or small-team agent, keeping state on the same server as the runtime, backed up and exportable, is a sensible starting point. As an agent grows, or needs to survive a server failure, the next step is to move state into a separate database or storage service with its own backups.<\/p>Three setups, three different answers<\/h2> The same three decisions lead to different setups, depending on what you’re building.<\/p>Setup<\/strong><\/td>Model<\/strong><\/td>Runtime<\/strong><\/td>State<\/strong><\/td>Main trade-off<\/strong><\/td><\/tr>Budget tinkerer<\/td> API or router<\/td> Small VPS or managed hosting<\/td> Same server, backed up<\/td> Prompts go to a provider<\/td><\/tr> Privacy-first self-hoster<\/td> Open model on a rented GPU<\/td> Self-managed VPS<\/td> On the VPS, under your control<\/td> More setup, hourly GPU costs<\/td><\/tr> Laptop-to-server builder<\/td> Local model, then API or router<\/td> Laptop, then VPS<\/td> Exported and moved with the runtime<\/td> One migration along the way<\/td><\/tr><\/tbody><\/table><\/figure>Take the budget tinkerer<\/strong>, running a Telegram assistant that summarizes articles and drafts replies. The model sits unused most of the day, which is exactly when per-token pricing costs nothing. The trade-off is that every prompt goes to a provider, so keep sensitive material out and set a spend limit on the key.<\/p>The privacy-first self-hoster’s<\/strong> catch is timing. A GPU that isn’t running can’t respond, so you either keep it running for the hours you need it or send non-sensitive tasks to an API. And the privacy has limits: your prompts avoid a model provider, but the hardware still belongs to the GPU provider, and your messaging platform still handles your messages.<\/p>The laptop-to-server builder<\/strong> is the case this framework was made for. When the agent needs to run overnight, the runtime and state move to a VPS, and the model switches to an API or router, since a standard VPS usually lacks a GPU. Because the three parts were never tangled together, that’s a move, not a rebuild.<\/p>Build for the model you’ll use next year<\/h2> The model you choose today probably won’t be the one you use next year.<\/p>
The setup that lasts is one where swapping the model is a settings change, not a rebuild, and never a reason to lose what your agent has learned. That’s what separating the three parts gives you: the model can change without touching the runtime, the runtime can move without losing its state, and the state stays yours wherever the model runs. When an agent takes a few clicks to deploy, what sets yours apart is that it keeps running, keeps its costs in check, and keeps your data yours. <\/p>
The simplest place to start is the part that has to stay on: move the runtime and its state to an always-on VPS<\/a>, and point the model at whichever API or router fits. Make the three decisions separately, and the hardware becomes the easy part.<\/p>A company can hide an infrastructure mistake in a budget line. A solo builder sees it on the next bill.<\/p>
<\/p>\n","protected":false},"excerpt":{"rendered":"
Your agent works perfectly on your laptop: a local model, a Telegram connection, answers in seconds. But then the laptop goes to sleep, and the agent goes quiet with it. So you mo\u2026<\/p>\n","protected":false},"author":670,"featured_media":10946,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_content_updated_date":"","footnotes":""},"categories":[2417],"tags":[2427,2430,2432,2431,264,2284,2434,2429,2307,2321,2268],"hashtags":[2435,2415,2396,2414],"class_list":["post-10940","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-insights","tag-ai","tag-ai-agent-infrastructure","tag-ai-router","tag-gpu-hosting","tag-hostinger","tag-infrastructure","tag-llm","tag-model","tag-technology","tag-vps-hosting","tag-website","hashtags-ai-agents","hashtags-artificial-intelligence","hashtags-hostinger","hashtags-vps"],"hreflangs":[],"_links":{"self":[{"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/posts\/10940","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/users\/670"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/comments?post=10940"}],"version-history":[{"count":7,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/posts\/10940\/revisions"}],"predecessor-version":[{"id":10952,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/posts\/10940\/revisions\/10952"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/media\/10946"}],"wp:attachment":[{"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/media?parent=10940"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/categories?post=10940"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/tags?post=10940"},{"taxonomy":"hashtags","embeddable":true,"href":"https:\/\/www.hostinger.com\/blog\/wp-json\/wp\/v2\/hashtags?post=10940"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Hostinger](\"https:\/\/imagedelivery.net\/LqiWLm-3MGbYHtFuUbcBtA\/wp-content\/uploads\/sites\/4\/2026\/11\/hostinger-gpu-customer-survey-2026.png\/w=1024,h=1024,fit=scale-down\")