Git Repository to Production: Dockup Deploy Guide

Moving a Git repository to production requires more than connecting a remote and pressing deploy. The platform must know the service target, branch, build method, start command, listening port, environment, health gate, and recovery path. Dockup makes those decisions explicit while supporting both automatic Nixpacks builds and repository-owned Dockerfiles.

This guide starts with a repository that has never been deployed and ends with a verified URL, deployment history, logs, and a tested rollback command.

What should be checked before the first production deploy?

Confirm that the repository is deployable without undocumented local state. A clean clone should contain everything needed to install dependencies and start the application, except secrets.

Use this checklist:

Check	Expected result
Default branch	The intended production branch exists
Dependency lockfile	Committed for reproducible installs
Start process	Binds to the configured port and 0.0.0.0
Health route	Returns success without external side effects
Database migrations	Have an explicit safe execution plan
Secrets	Stored outside Git
Persistent files	Use a volume, not the container filesystem
Rollback	Previous deployment can be rerun

Install the CLI and authenticate:

npm install -g dockup-cli
export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

List existing services before creating anything:

dockup services --json

This prevents duplicate resources and confirms the exact workspace and target convention.

How does Dockup create support Git deployment?

The usual first-deploy command creates the service, deploys it, waits for the result, and links the current directory:

dockup create api \
  --repo https://github.com/acme/api \
  --project production \
  --branch main \
  --deploy \
  --wait \
  --link \
  --json

The resulting target is production/api. The .dockup link lets later commands resolve that service when run inside the repository, but production documentation should still record the full target.

After an interrupted provisioning attempt, list services and inspect the exact target before running creation again:

dockup services --json

If production/api already exists, continue by reading its status and deployment history. This avoids turning an uncertain network result into a duplicate service. Keep repository access credentials outside source control and command output.

How does Dockup choose Nixpacks or Dockerfile?

If the repository contains a Dockerfile, Dockup uses it. Otherwise, Nixpacks detects the application and builds it automatically. That ordering makes the repository’s explicit container definition authoritative.

Nixpacks is a good first choice when the application follows common ecosystem conventions and does not need operating-system-level customization. A Dockerfile is useful when you need a specific base image, system packages, multi-stage build, custom runtime user, or exact copy boundaries.

You do not need to add an empty Dockerfile merely to “look production ready.” An incorrect Dockerfile can be less reproducible than a conventional automatic build. Use the decision process in Nixpacks vs Dockerfile.

Inspect the service after creation:

dockup info production/api --json

The response includes repository URL, branch, deployment type, port, build and start settings, environment keys, custom domains, and latest deployment data.

If the detected commands need an override, use documented settings:

dockup set production/api \
  --build "npm ci && npm run build" \
  --start "npm start" \
  --port 3000 \
  --json

Settings apply on the next deployment.

How do you configure production environment and health?

Add ordinary values and secrets separately:

dockup env set NODE_ENV=production \
  -s production/api \
  --json

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

Secret values are masked when the environment is listed. They can be set or replaced, but the stored value is not returned.

Environment changes require a redeploy because the running process cannot receive a new environment retroactively. The full lifecycle is explained in environment variables and secrets.

Configure a health gate that represents readiness:

dockup health production/api \
  --path /healthz \
  --interval 5 \
  --timeout 3 \
  --retries 5 \
  --json

Dockup uses a zero-downtime blue-green flow and only sends traffic to the new deployment after readiness succeeds. When no HTTP path is configured, the gate can fall back to TCP port readiness.

A health route should verify that the application process is ready to serve requests. Avoid making it perform destructive checks or expensive full-system tests. Deep dependency checks can create false outages when an optional service is degraded.

How do you deploy, watch, and verify production?

Trigger the release and wait for a terminal state:

dockup deploy production/api --wait --json

The default timeout is 900 seconds. Exit 0 means success. deploy_failed and deploy_timeout are non-zero results, so shell scripts and CI systems stop correctly.

To watch the build as NDJSON:

dockup logs production/api --build -f --json

The stream ends at success or failure. If the build succeeds but the container crashes, inspect runtime logs:

dockup logs production/api --json

After a successful release, verify the platform state and public behavior:

dockup status production/api --json
dockup uptime production/api --hours 24 --json
dockup security production/api --json

Uptime probes run every minute and report average and p95 response time. Security scanning checks image CVEs and configuration. Add an application-specific smoke test for the actual business endpoint; platform readiness is necessary but not sufficient.

The detailed log method is available in build and runtime log debugging.

How should automatic deploys and previews be introduced?

Do the first production release manually enough to observe each boundary. Once the build, health gate, and rollback path are known, enable deployment on push:

dockup auto-deploy production/api --on --json

Automatic deployment should follow a protected branch and code-review policy. A push is a production trigger, so repository permissions become infrastructure permissions.

Pull request and branch previews provide isolated URLs and environments:

dockup pr-preview production/api --on --json
dockup preview branch feature/login production/api --json

In a private-networking project, previews join the project network. They can reach the same production database at <slug>.internal, but Dockup creates an automatic read-only database user for the preview. The preview can inspect production-shaped data without writing to it.

This does not eliminate privacy obligations. Preview access should still be limited, audited, and used only where reading production data is permitted.

How do you roll back a bad deployment?

Preserve evidence before recovery. Read build logs for a build failure and runtime logs for a crash. Then list deployment history:

dockup deployments production/api -n 20 --json

Select a deployment ID whose status and timestamp are known, then rerun it:

dockup rollback <deploymentId> production/api --json

A rollback should be an explicit incident action. Record the failed deployment ID, selected recovery ID, reason, and follow-up fix. If a database migration is not backward compatible, application rollback alone may not restore compatibility; migration design must be part of the release plan.

The zero-downtime deployment guide explains the traffic cutover, while the Dockup CLI reference documents all command flags.

First-deploy completion record

At the end of the Git repository to production workflow, capture:

• Exact project/service target.
• Repository and production branch.
• Build method: Nixpacks or Dockerfile.
• Build and start commands when overridden.
• Listening port and health path.
• Deployment ID and terminal status.
• Production URL and custom domain plan.
• Uptime and security verification.
• Rollback deployment ID or selection rule.

This record turns the second deployment into a routine operation rather than another discovery exercise.

Separate application state from the container image

The writable filesystem inside a service container should be treated as replaceable. A new deployment creates a new version, and a rollback reruns an older image; files written only inside the old container are not a durable data strategy.

Use managed databases for relational, document, or cache state, and attach a volume for files that must persist across deployments. Confirm mount paths before the first production release. A containerized upload directory that was never mounted can appear healthy until the next deploy removes the data.

Review persistent volumes and snapshots before moving user-generated files. For database state, use the database-specific backup system rather than treating a hot volume snapshot as a transaction-consistent backup.

Estimate the first month without inventing a fixed instance bill

Dockup measures CPU, RAM, and disk consumption per minute and subtracts usage from the plan balance. The Free plan includes $2.50 starting credit and up to three deployments; the recommended Go plan costs $20 per month and includes $20 usage credit.

After the service has real traffic, review its CPU, RAM, and disk consumption in app.dockup.ai. Use observed per-minute consumption—not a guessed maximum—to decide whether the service, database, or persistent disk needs adjustment.

Verify a clean second deployment

After the first release, make a harmless reviewed change and deploy again. This confirms that the repository link, build cache assumptions, health gate, environment, and history work as an ongoing process rather than a one-time provisioning success.

Keep the target explicit

Record the final project/service string.

Preserve the release URL

Record the production URL beside the deployment ID.

Confirm the next trigger

Record whether future releases are manual or use optional deploy-on-push. This keeps repository permissions, branch protection, and production expectations aligned after the first deployment.

Start with a verifiable deployment

Choose a small repository with a clear start command and health route, then document the exact target and rollback ID after the first successful release.

Start free at app.dockup.ai. The Free plan is $0 per month, includes $2.50 in starting credit, and supports one workspace, three databases, and three deployments.

FAQ

Can Dockup deploy a repository without a Dockerfile?

Yes. When no Dockerfile is present, Dockup uses Nixpacks to detect and build the application automatically.

What does dockup create --link do?

It writes a .dockup link in the current directory so later commands can resolve the associated project/service target.

Why should the first deploy use --wait?

It keeps the command attached until the deployment reaches success, failure, or timeout, and returns an exit code that accurately represents the terminal result.

Do environment variable changes apply immediately?

No. They apply to a new container on the next deployment, so redeploy the service after changing environment configuration.

How does Dockup roll back an application?

List deployment history, identify a known previous deployment ID, and use dockup rollback with that ID and the exact service target.