Self-hosted agents vs Cloud agents
This is usually framed as a security argument, which undersells it. Where the agent runs decides what your trust boundary contains, which credentials exist where, and whether a person can realistically be in the loop when the agent stops to ask something.
Which model should we be running?
If your work is entangled with your own environment, or your code and credentials must not sit on somebody else infrastructure, self-hosting is the answer and your problem becomes supervising it. If you want work to proceed without depending on a machine being awake, and a provisioned environment is acceptable, cloud agents remove real operational burden. Most teams end up doing both for different kinds of work.
What each one actually is.
The distinction is about hosting, not autonomy. Both models run agents that work on their own for long stretches.
Self-hosted agents
The agent runs on a machine you control: your laptop, a workstation, or a box in your own infrastructure. It uses the environment already there, including your working tree and your credentials.
- Code and credentials never leave hardware you own
- The environment is the real one, with all its existing state
- You own the machine: patching, access, and whether it is awake
- Model access runs under the subscription you already hold
Cloud agents
The agent runs in an environment the vendor provisions and operates. You describe work, the platform runs it somewhere else, and you review what comes back.
- Nothing depends on a developer machine being on
- A clean environment every time, provisioned to spec
- Your code and granted credentials are present on vendor infrastructure
- Compute and often model access are bundled into the price
Where they diverge.
The dimensions that actually change your decision, rather than every dimension that exists.
| Dimension | Self-hosted agents | Cloud agents |
|---|---|---|
| Where code executes | On hardware you own and operate. | On infrastructure the vendor provisions. |
| Where credentials live | On your machine, where they already are. | Granted to the hosted environment. |
| Environment | The real one: your tree, your tooling, your half-finished state. | Clean and provisioned, which helps isolated work and hinders entangled work. |
| Availability | Depends on your machine being on and reachable. | Independent of any developer machine. |
| Who patches it | You do, along with access control and machine hygiene. | The vendor, as part of the service. |
| Model billing | Your own subscription, in the interactive case. | Usually bundled, or metered by the platform. |
| Supervision problem | The agent is right there but you are often not. Reaching it is the hard part. | The run is reachable but remote from your environment. |
What the framing usually hides.
The self-hosted case is normally argued on security alone and the cloud case on convenience alone. Both arguments skip the part that decides how the day actually goes.
Self-hosting is treated as automatically safer
Keeping execution inside your boundary genuinely removes a class of exposure. It also makes you responsible for the machine: who can reach it, whether it is patched, what else is on it. That is a real trade rather than a free win, and it is worth stating before choosing.
Nobody costs the supervision problem
A self-hosted agent sits on a machine you are frequently away from. When it stops to ask permission, it waits. A request that takes two seconds to answer can idle a run for hours, and that cost is invisible in a hosting comparison because it is not a hosting property.
Hosting gets confused with how much freedom the agent has
A cloud agent is not more autonomous because it is hosted, and a self-hosted one is not more supervised because it is local. Autonomy comes from the permission policy you set. The two choices are independent, and conflating them is how teams end up with an unsupervised agent on their own hardware.
Which one fits your situation.
Neither is the advanced version of the other. They answer different questions, and plenty of teams end up wanting both.
Reach for self-hosting when
- Your code, credentials, or execution must stay inside your own boundary.
- The work depends on your real environment rather than a clean one.
- You want model access under the subscription you already pay for.
- You can solve the supervision half, so a waiting agent is not a stalled one.
Reach for cloud agents when
- Work must proceed without depending on a developer machine being awake.
- Tasks are isolated enough that a clean provisioned environment is an advantage.
- You would rather the vendor owned patching and machine hygiene.
- Granting credentials to hosted infrastructure is acceptable to you.
Virex takes the self-hosted side, and fixes what it costs you.
The weakness of self-hosting is not security, it is that you are rarely at the machine. That is the part Virex Remote is built to solve.
Execution stays with you
Your code, credentials, and execution stay on your machines. Virex never runs customer code. What leaves is session state and coordination, so you can watch and steer.
You do not have to be at the desk
Follow a live session and answer its permission and plan decisions from any browser or device, so a run waiting on a person is a two-second interruption rather than a lost night.
Attributable afterwards
Who approved what, and when, is recorded. Supervised autonomy only means something if the supervision can be checked later.
Self-hosted and cloud agent questions
What is the difference between self-hosted and cloud agents?
A self-hosted agent runs on hardware you control, using your own environment and credentials. A cloud agent runs on vendor infrastructure that is provisioned for you. The split decides where your code executes and whose machine holds your credentials.
Does Virex host the agent?
No. Agents run on your machines. Virex is a control plane: session state and coordination signals leave your machine so you can watch and steer a run, while code, credentials, and execution stay on your hardware.
Is self-hosting always more secure?
Not automatically. It keeps execution inside your boundary, which removes a class of exposure, but you then own patching, access control, and the state of the machine. It relocates the responsibility rather than removing it.
Can cloud agents work on a private repository?
Generally yes, with credentials granted to the hosted environment. That is the trade being made: convenience in exchange for your code and credentials being present on infrastructure you do not run.
Which suits an unattended overnight run?
Either can run unattended. The real question is what happens when the agent stops to ask something. A cloud agent usually has policy decide for it, and a self-hosted agent with a control plane can reach a person instead.
Keep the agents on your hardware.
Virex Remote gives you the oversight self-hosting normally costs you, without moving your code anywhere.