From a Git Revision to an Immutable Preview URL

Point OpenFactory at a supported repository and queue an immutable preview deployment. It resolves a revision, builds, boots, health-checks, and, after success, hands you a route like https://myapp.apps.openfactory.tech, public or owner-gated according to the requested visibility. This is a preview workflow, not a production-readiness or uptime guarantee.

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 exposes that chain as one asynchronous deployment request. A successful request produces a health-checked, addressable candidate; a failed request preserves the stage and error for diagnosis.

Git in, live app out

The deploy pipeline takes a resolved Git revision and walks it through the steps you would do by hand, reliably and in order. It detects a supported stack (Node or a simple 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 route 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.

An app-scoped route across successful cutovers

Every deployed app gets an address on the apps.openfactory.tech domain, with HTTPS handled for you. The important part is that the route is stable for that registered app slug: successful restarts and redeployments continue to use the same address. You can reference it from a pull request or test, while still treating availability as an operational dependency rather than a guaranteed property.

Public to the world, or private to you

Not every preview belongs on the open internet. Each route can be public, meaning anyone with the link can load it, or private, which requires your authenticated session, so the owning authenticated user 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 intended to be gated by the gateway. Because current tool defaults are public, request private visibility explicitly and test logged-out access; do not place production data or secrets in a preview merely because it is marked private.

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, and then review the verdict and evidence. An agent can orchestrate the loop, but deployment success and test success remain separate states.

What gets detected, and what you skip

The first stage of the pipeline is detection, and it is deliberately bounded. OpenFactory currently recognizes package.json-based Node projects and simple static sites; other repositories need explicit commands and a port, or fail before a candidate is built. For supported projects it 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. For the supported path you may not need a Dockerfile or hand-written reverse-proxy configuration. You can still override install, build, run, port, output-directory, and base-image choices when inference is insufficient. 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 a candidate and checks for an HTTP response before switching the route. That health check is narrow: it does not prove application correctness, dependency safety, capacity, or recovery behavior.

Isolate branches with distinct app records

Routes are per registered app, not automatically per Git branch. If two branches need simultaneous previews, create separate app records and unique slugs for them. Reusing one app record with a branch override updates that app's candidate and route; it does not create an isolated branch URL. Put the chosen revision and app id in the review record so a reviewer knows exactly what the link represents.

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 run evidence to the same pull request. A green result means that defined workflow passed on that run; it does not certify the whole change.

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 also takes supported repositories to running preview VMs and can test their routes. Customer-controlled hosting is a deployment-boundary choice to validate in a technical pilot; the hosted service should not be described as keeping every dependency, model call, or connected account on customer-owned hardware.

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, keep the preview disposable and observable. The pipeline reduces setup work, while the application owner still reviews build provenance, logs, access, test scope, data handling, and teardown.

How to deploy

• Ask in chat. Name the repository, branch or revision, visibility, expected stack, health path, and whether the request may publish a route. Review the generated tool arguments before relying on them.
• 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 resulting URL show up at console.openfactory.tech.

Deploy the web app in my git repo and give me its preview 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.

A supported revision can move through an observable preview pipeline and into a test run against the resulting route. Pair it with one-click test groups to collect repeatable workflow evidence, then retain human release and security judgment outside the agent's sole control.