Deploying a project from Git

A Git project separates source acquisition from deployment. Connecting the repository creates a project record and immediately starts analysis in the current console. The form requires a project name and HTTPS clone URL, with optional branch and personal access token fields. The token is intended for private repository access and is encrypted before storage. The project records the resolved branch, last commit identifier and commit message returned by the clone operation. A repository URL alone is not deployable: the analysis stage must produce a blueprint before the deployment endpoint will accept a run.

Connect the repository deliberately

Open Projects, select Connect Source and remain on the Git Repository tab. Use a name that distinguishes the application in the console; directories and Docker resources are made unique with the project identifier, so names do not need to be globally unique. Enter the clone URL and specify a branch only when analysis should not follow the repository default. Add a personal access token only where cloning requires authentication. The project can later be edited to change its URL, branch or token, but a new analysis is required to refresh the checked-out source and generated blueprint.

Let analysis establish the deployment inputs

Analysis clones the selected source into a workspace, records top-level entries and file count, and inspects it for language, stack, application port, environment keys and supported database dependencies. The result includes a Dockerfile, a generated Compose file, an Nginx virtual host, an environment template and warnings. The project moves through fetching and analysing states before becoming ready. If clone or analysis fails, its status becomes failed and the project retains the error. Correct repository access or source configuration, then use Re-Analyze rather than starting a deployment from a stale or absent blueprint.

Review generated files as executable configuration

The project detail page exposes four editable tabs: Dockerfile, docker-compose.yml, nginx.conf and the .env template. These are not explanatory previews. During deployment the saved Dockerfile and Compose configuration are written into the remote project directory, and the Nginx template is used when a domain is selected. Review the detected port, build command, startup command and any environment values the application actually requires. Saving the blueprint persists all four editor values and marks the blueprint manual. Re-analysis can generate a new blueprint, so source changes and deliberate manual changes should be reconciled before deployment.

Select a server and optional domain

The Deploy dialog lists servers whose recorded status is online or ready. A target server is mandatory. A domain is optional and is selected from domains already configured for the team. The API confirms that project, server and domain belong to the team, that a blueprint exists and that the project and server remain writable under the current plan. It does not infer server readiness from the form alone; preflight still checks that Docker and Compose are available. If no domain is selected, publication through Cloudflare and Nginx is skipped rather than synthesised from the project name.

Follow the runner in order

A deployment is queued and then runs through SSH connection, preflight, source upload, database provisioning, configuration, image build, container start, optional DNS and certificate work, proxy publication and local verification. Source is packed, transferred to the project-specific directory and extracted before configuration is written. Docker Compose builds with pull enabled and starts services in detached mode while removing orphan containers. The final check requests the application's loopback host port. An HTTP response establishes that the process answered; a missing response fails the run with a port-specific explanation even if Docker reports the container as running.

Re-analysis and redeployment are separate

Connecting Git is not a continuous-delivery webhook. The implementation exposes an explicit Re-Analyze action and an explicit Deploy action. Re-analysis fetches source and updates the stored commit and blueprint; deployment packages the analysed workspace and uses the saved blueprint. This separation makes the exact configuration inspectable, but it also means a new repository commit is not asserted to deploy itself. Before releasing a change, confirm analysis completed against the intended branch and commit, inspect any regenerated files, save required edits and then start the deployment against the intended server and domain.