From a Git Repo to a Live URL: Deploy Web Apps on OpenFactory

Point OpenFactory at a git repo and get back a live HTTPS URL. It detects the stack, installs, launches, health-checks, and hands you a link like https://myapp.apps.openfactory.tech — public to the world or private to you, and stable across restarts.

Standing up a preview of a web app is one of those tasks that is easy to describe and tedious to do. Provision a box, install the right runtime, pull the code, install dependencies, pick a port, keep the process alive, wire up a domain, terminate TLS, and add just enough access control that you are not publishing your half-finished app to the entire internet. Each step is small; together they are an afternoon, and they stand between “it works on my laptop” and “here is a link you can click.”

OpenFactory collapses that afternoon into a single action. Give it a repository — or just ask for it in chat — and it produces a working, addressable app.

Git in, live app out

The deploy pipeline takes your repository and walks it through the same steps you would do by hand, reliably and in order. It detects the stack (a Node service, a static site), installs dependencies, launches the app as a managed, long-running service, health-checks it to confirm it actually came up, and registers a public URL that routes to it. If a step fails, it tells you which one — you are not left guessing whether the build broke or the port was wrong.

A real URL, stable across restarts

Every deployed app gets a address on the apps.openfactory.tech domain, with HTTPS handled for you. The important part is that the route is stable: restart the app, redeploy a new build, come back tomorrow — the URL stays the same. That is what makes it safe to paste the link into a pull request, send it to a reviewer, or hand it to an automated test, because the address you shared keeps pointing at the app.

Public to the world, or private to you

Not every preview belongs on the open internet. Each route can be public — anyone with the link can load it — or private, which requires your authenticated session, so only you (and whoever you choose) can reach it. A marketing page or a demo you want to share goes public; a work-in-progress with real data stays private. The gateway enforces it at the edge, so a private app is not quietly reachable by guessing the URL.

Deploy, then test — the full loop

A live URL is most powerful when it feeds straight back into testing. Deploy a branch to its own URL, then point OpenFactory's app test group at that address and let the AI drive every workflow on it. Build, deploy, test, read the verdict — the whole loop lives on one platform, and an agent can run it for you end to end.

What gets detected, and what you skip

The first stage of the pipeline is detection, and it is the stage that saves you the most fiddling. OpenFactory looks at the repository and works out what kind of app it is — a Node service that needs its dependencies installed and a start command, or a static site that just needs to be served. From that it derives the things you would otherwise configure by hand: which runtime to use, how to install, how to launch, and which port the app listens on so the gateway can route to it.

Everything downstream follows from that detection. You do not write a Dockerfile, you do not pick a base image, you do not hand-roll a process manager, and you do not edit a reverse-proxy config. The pipeline launches the app as a managed, long-running service so it survives and restarts cleanly, then health-checks it before declaring success — which means a URL you are handed is one that actually responded, not one that merely got created. When detection can't fully infer something, the failure is specific and early, so you fix the one real issue instead of bisecting a silent breakage.

A preview for every branch

Stable, per-app URLs unlock the workflow people actually want from preview deploys: a living link for each thing you are working on. Deploy your feature branch and share its URL in the pull request; a reviewer clicks it and sees the change running, not a screenshot of it. Because the address is stable across restarts and redeploys, that link keeps working as you push fixes — the reviewer refreshes and gets the latest, rather than chasing a new URL every time.

This is where deploy and test stop being separate activities. A preview URL is exactly the kind of thing OpenFactory's tests are built to point at: deploy the branch, run its app test group against the fresh URL, and attach the verdict to the same pull request. The reviewer gets a link to click and a green check that an AI actually exercised the workflows — two forms of confidence from one deploy.

Private by default, public on purpose

The access model deserves a second look because it is easy to get wrong elsewhere. The common failure mode of preview deploys is that they are secretly public: anyone who guesses or stumbles onto the URL can load your unfinished app and whatever data it is pointed at. OpenFactory makes the choice explicit and enforces it at the gateway. A private route requires your authenticated session, so a work-in-progress stays visible only to you and the people you bring in. A public route is open by design — the right setting for a marketing page, a demo, or a finished app you want the world to reach.

Because the gating happens at the edge, a private app is genuinely not reachable without a valid session — it is not relying on an unguessable URL for its security. You publish when you mean to publish, and not a moment before.

Built on the same foundation as your images

Deploying an app fits into the broader OpenFactory model rather than sitting beside it. The same platform that builds custom Linux images and stands up self-hosted stacks now also takes a repository to a running, addressable web app — and then tests it. And because OpenFactory is self-hostable, you can run the whole loop on infrastructure you control, keeping your code, your previews, and the accounts your app talks to on hardware you own rather than shipping them into someone else's platform.

Where it shines

A few patterns come up again and again. Pull-request previews: deploy the branch, drop the link in the PR, and let reviewers click through the actual change. Demos: stand up a public URL for a prospect or a conference talk without provisioning anything yourself.Throwaway environments: spin a branch up to reproduce a bug against real routing and TLS, then tear it down when you are done. And agent-built apps: when an agent writes or modifies an app, it can deploy the result to a URL in the same breath and hand you something to click rather than a diff to imagine.

In every one of these, the deploy is the boring, reliable part — which is exactly what you want. The interesting work is the app itself and the confidence that it runs; OpenFactory makes the path between them a single step, and then lets you verify it with the same tests you would run anywhere else.

How to deploy

• Ask in chat. “Deploy this repo and give me the URL” is enough; OpenFactory runs the pipeline and replies with the link.
• Use the MCP tools. create_app, deploy_app, list_apps, and get_app manage the full lifecycle for agents and scripts.
• Watch it in the console. Deploy status and the public URL show up at console.openfactory.tech.

Deploy the web app in my git repo and give me the public URL.

Detect the stack, install dependencies, start it, health-check it, and
register a preview URL. Keep it private to me for now. Then run my
"booking" app test group against the new URL and summarize the results.

From a repository to a link you can click — and then straight into a test run against that link. Deploying a preview should be one step, and now it is. Pair it with one-click test groups and you have a build-to-verified loop that an agent can run while you move on to the next thing.