What Deploy Bridge is
Deploy Bridge turns source code into a recorded deployment on a Linux server supplied by the account holder. It combines source analysis, container deployment, optional database provisioning and Cloudflare-backed routing.
Deploy Bridge is an orchestration service for applications that run on a Linux server controlled by the account holder. It is not a compute provider and does not allocate a machine. A server is registered with SSH connection details, checked for reachability and, when required, provisioned with Docker Engine, Docker Compose and Nginx. Deployments then use that SSH connection to place source and generated configuration on the machine. The resulting containers, project directories, database volumes and reverse-proxy configuration remain on that server rather than inside a proprietary application runtime.
Source becomes an editable blueprint
A project begins with either a Git clone URL or a ZIP archive. For Git projects, an optional branch and personal access token can be supplied; the token is encrypted before storage. Analysis checks out the source, identifies the stack, language, application port and database dependencies, then stores a deployment blueprint. That blueprint contains a Dockerfile, Docker Compose file, Nginx virtual-host configuration and environment template. Each file is visible in the project console and can be edited before deployment. Saving an edit marks the blueprint as manually generated rather than silently replacing the source repository.
A deployment is a sequence, not one shell command
Starting a deployment selects a project, a target server and, optionally, a configured domain. The server must belong to the same team, the project must already have a blueprint and neither resource may be read-only after a plan downgrade. The runner connects over SSH, checks Docker and Compose, uploads the project, provisions detected databases, writes configuration, builds and starts the application container. Domainless deployments skip DNS, certificate and proxy work. Every stage has its own status, timing and detail, while command output is retained as deployment log entries.
Infrastructure stays ordinary
Each project receives a distinct directory beneath /opt/deploy-bridge, a stable loopback host port and a project-specific Docker network. The generated Compose configuration starts the application, while detected PostgreSQL, MySQL, MongoDB or Redis dependencies run as sibling containers. Database data is stored in named Docker volumes, and an existing database for the same project, server and engine is reused on later deployments. This design matters operationally: redeploying application code does not deliberately replace the database volume, and stopping use of Deploy Bridge does not convert the machine into an unreadable platform artefact.
Domains are a deployment concern
Public routing currently integrates with Cloudflare. A Cloudflare API token is verified before storage and used to enumerate available zones. A domain record stores the intended hostname, zone and proxy setting, but adding it does not publish the application. During a deployment that selects the domain, Deploy Bridge upserts an A record to the server address, generates the certificate private key on the server, sends a certificate signing request to Cloudflare Origin CA and installs the returned certificate. It then tests the Nginx configuration before reloading Nginx and performs a local HTTP check against the application port.
The agent intervenes only after failure
The build agent is attached to a tracked run after the SSH connection succeeds, provided an AI provider is active. When a step fails, it receives the failing step, recent output, generated build files and prior interventions. A proposed remediation is validated against a schema and classified before execution. Narrow changes such as a safe Dockerfile edit can run unattended. Host package installation, Nginx edits, unrecognised commands and other host-reaching changes pause the deployment for approval. If no provider is configured, no usable remediation is produced or the allowance is exhausted, the original deployment fails visibly.
The console is the operational record
The console lists projects, servers, domains and deployments separately because each has a different lifecycle. Server checks expose distribution, kernel, resource totals, installed tool versions and known containers. Project pages expose analysed files and the editable blueprint. Deployment pages show ordered steps, progress, logs, agent proposals and their outcomes. This record does not make Deploy Bridge a monitoring or backup service. It explains what the deployment runner attempted and what the machine reported during those operations; application observability, host backups and database recovery remain separate operational responsibilities.
Common questions
Does Deploy Bridge provide a server?
No. A Linux server must be supplied and registered with SSH credentials. Deploy Bridge provisions and deploys to that machine but does not resell compute.
Does an application stop if the subscription ends?
The application runs in ordinary containers on the supplied server, so cancellation does not itself stop those containers. Access to orchestration, the agent and deployment history is what ends.
Can Deploy Bridge deploy without a domain?
Yes. A domain is optional when a deployment is started. DNS, certificate and Nginx publication steps are skipped, and the runner verifies the application through its loopback host port.
Deploying something unusual?
If your stack does not fit what is documented here, describe it. The platform handles more than the defaults, and where it does not, we would like to know.
