A Service is a workload declared in a connected GitHub or GitLab repository. Towbar can build a committed source revision, run a prebuilt OCI image, or deploy a Compose workload. Supporting software such as an analytics server or metrics collector is also a Service. Use a Datastore when Towbar provides engine-specific storage, connections, and recovery.
Towbar keeps the desired configuration in Git. The dashboard shows the effective manifest, secret status, deployment history, logs, and current state; it does not create a second workload definition.
One manifest id identifies the service across renames and file moves. A Repository sync imports that declaration for each mapped environment, but leaves the currently running release alone. A deployment then builds or resolves an image and promotes it on the environment’s server after its checks pass. The service can reach a Datastore on the same private Docker network; its connection credentials live in Towbar secrets rather than Git. A Preview is a separate, temporary instance for an eligible pull request.
Public Services use the configured domain favicon when one is available. The
current state and latest deployment attempt appear in separate widgets.
Define a Service
Create one file under .towbar/services and give it a stable id. This minimal Dockerfile Service listens on port 3000 in production:
.towbar/services/web.service.yml
production in towbar.yml, map it to a branch, and register the example server IP before syncing. See the Service manifest for every top-level field and the rules for environment overrides.
Container and health covers process ports, capacity, private networks, persistent volumes, and readiness. Routing and TLS covers domains and certificates. Declare secret names in the manifest and save their values in Secrets.
Pick a deployment mode
Use an existing Dockerfile, build a static site, run a prebuilt image, or choose Railpack, Nixpacks, or Cloud Native Buildpacks. A multi-service project uses Compose. Deployment modes compares them and explains build servers and rollout strategies.
Deploy and verify
Open the Service and choose Deploy. Follow the stages until the attempt reaches a final result, then verify the service response. Start with a manual deployment; enable automatic deployment and previews after the basic path works. Deployments and releases explains image promotion and rollback.
Scheduled jobs
Declare recurring commands in the Service manifest and deploy that configuration before a job can run. Scheduled jobs covers cron, runtime access, output, overlap, manual runs, and pause behavior. 
