Factory's Remote Control lets its Droid coding agents run on a persistent machine the user already manages, such as a VPS, cloud VM, workstation, or on-prem server. Each machine is scoped to an individual user or service , so a Droid returns to the same filesystem, credentials, installed dependencies, running processes, and accumulated context every time it picks up a task. For developers and platform teams already running Factory, this is the self-managed counterpart to Factory-hosted Droid Computers, aimed at anyone who needs agents working inside private networks or against pre-configured environments rather than fresh cloud sandboxes.
The timing matters because Factory has been pushing the argument that serious software engineering workflows beyond short coding tasks are inherently stateful, and the environments agents run in need to be stateful too . Remote Control extends that bet to infrastructure the customer controls, which several Fortune 500 companies are already using in production through the Bring Your Own Machine path. Practically, it unlocks background and asynchronous use cases where a Droid keeps running after the laptop closes, resumes with memory intact, and compounds skills across sessions instead of rebuilding context each run.
Factory is led by co-founder and CEO Matan Grinberg , and the company has been building task-specific AI agents for autonomous software engineering with adoption across large enterprises. Remote Control slots alongside the managed cloud option announced earlier in the Droid Computers rollout, giving teams a choice between Factory-provisioned machines and their own hardware without changing how Droids are orchestrated from the web, desktop, or mobile app.
Comments (14)
Sign in to join the discussion.
N
Nikhita R.20h ago
ok wait, persistent remote machine per droid is actually the piece that was missing. local sandboxes were cute but my branches kept amnesia-ing themselves.
J
Jonas Bergkamp20h ago
the demo cuts are suspiciously clean. anyone got a raw unedited run where the droid has to recover from a broken apt-get?
H
Henrik Volkov19h ago
reliability question: if the persistent machine goes down mid-task, does the droid resume from checkpoint or faceplant? real orgs need the boring answer here.
O
Omolade Kuti20h ago
hot take: by Q2 next year nobody will remember what 'ephemeral agent runtime' meant and we'll all pretend we always had persistent envs.
M
Marco P.19h ago
persistent machines means persistent compute cost per seat. curious how the margin math shakes out when a droid idles for 14 hours between tasks. interesting.
J
Juno Eom19h ago
respectfully, is anyone from the team willing to chat on background about how this changes the pricing tier structure? asking for an article, not for me.
S
sora19h ago
the voiceover pacing in that launch vid is doing a lot of work. whoever edited it earned their coffee this week.
P
Priya Devaraj19h ago
scoped to an individual user OR service is the sneaky good line here. service accounts for droids unlock a lot of CI patterns people haven't thought through yet.
T
Tapiwa Moyo19h ago
one more thing for the roadmap: let me snapshot a droid's machine state and fork it for a parallel branch. you know you want to.
B
Bogdan Chen19h ago
what's the story on data residency for teams in the EU? self-managed usually implies BYO region but the post is coy about it.
F
Fatimah Qureshi19h ago
please tell me there are webhooks for machine lifecycle events. if I have to poll a status endpoint to know my droid finished I will riot politely.
D
Dan Oyelaran19h ago
3 weeks out from shipping my own agent harness and this launch just invalidated roughly 40% of my repo. love that for me.
M
Mira Reyes19h ago
the thread structure is a masterclass in restraint. one tweet, one gif, no 14-part essay. more of this please.
Z
zed19h ago
this might be the final coding tool launch where a human still writes the release notes. screenshot it for the museum.
Work With Us
Book an intro call to explore our suite of services. We might have a waitlist.
Factory
Droids on a persistent remote machine
Droids on a persistent remote machine
Tags
TLVC Rating
Community Rating
No ratings yet
to rate this launch.
Factory's Remote Control lets its Droid coding agents run on a persistent machine the user already manages, such as a VPS, cloud VM, workstation, or on-prem server. Each machine is scoped to an individual user or service , so a Droid returns to the same filesystem, credentials, installed dependencies, running processes, and accumulated context every time it picks up a task. For developers and platform teams already running Factory, this is the self-managed counterpart to Factory-hosted Droid Computers, aimed at anyone who needs agents working inside private networks or against pre-configured environments rather than fresh cloud sandboxes. The timing matters because Factory has been pushing the argument that serious software engineering workflows beyond short coding tasks are inherently stateful, and the environments agents run in need to be stateful too . Remote Control extends that bet to infrastructure the customer controls, which several Fortune 500 companies are already using in production through the Bring Your Own Machine path. Practically, it unlocks background and asynchronous use cases where a Droid keeps running after the laptop closes, resumes with memory intact, and compounds skills across sessions instead of rebuilding context each run. Factory is led by co-founder and CEO Matan Grinberg , and the company has been building task-specific AI agents for autonomous software engineering with adoption across large enterprises. Remote Control slots alongside the managed cloud option announced earlier in the Droid Computers rollout, giving teams a choice between Factory-provisioned machines and their own hardware without changing how Droids are orchestrated from the web, desktop, or mobile app.
Comments (14)
ok wait, persistent remote machine per droid is actually the piece that was missing. local sandboxes were cute but my branches kept amnesia-ing themselves.
the demo cuts are suspiciously clean. anyone got a raw unedited run where the droid has to recover from a broken apt-get?
reliability question: if the persistent machine goes down mid-task, does the droid resume from checkpoint or faceplant? real orgs need the boring answer here.
hot take: by Q2 next year nobody will remember what 'ephemeral agent runtime' meant and we'll all pretend we always had persistent envs.
persistent machines means persistent compute cost per seat. curious how the margin math shakes out when a droid idles for 14 hours between tasks. interesting.
respectfully, is anyone from the team willing to chat on background about how this changes the pricing tier structure? asking for an article, not for me.
the voiceover pacing in that launch vid is doing a lot of work. whoever edited it earned their coffee this week.
scoped to an individual user OR service is the sneaky good line here. service accounts for droids unlock a lot of CI patterns people haven't thought through yet.
one more thing for the roadmap: let me snapshot a droid's machine state and fork it for a parallel branch. you know you want to.
what's the story on data residency for teams in the EU? self-managed usually implies BYO region but the post is coy about it.
please tell me there are webhooks for machine lifecycle events. if I have to poll a status endpoint to know my droid finished I will riot politely.
3 weeks out from shipping my own agent harness and this launch just invalidated roughly 40% of my repo. love that for me.
the thread structure is a masterclass in restraint. one tweet, one gif, no 14-part essay. more of this please.
this might be the final coding tool launch where a human still writes the release notes. screenshot it for the museum.