Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstalliTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers VPS plans with one-click Coolify, NVMe storage and a 14-day free trial.
Choose the Coolify deployment method that matches the artifact you already maintain. Use a Git repository for versioned application source, a standalone Dockerfile when that file is the complete build input, Git-based Docker Compose when a repository defines several services and their runtime wiring, an existing Docker image when another system already publishes the artifact, and a one-click Service when Coolify has a maintained template for the software.
The choice determines what Coolify receives. It does not, by itself, determine where the workload runs: Docker on a connected server runs your application, database, or service, while Coolify coordinates deployment from its control plane.
Recommended Free Tools
Quick decision table
| Your situation | Recommended path | Why it fits |
|---|---|---|
| Application source is in Git and should deploy on commits | Git repository | Versioned source, selectable build strategy, webhooks, and pull-request previews |
| A single custom image is completely defined by one Dockerfile | Dockerfile without Git | The Dockerfile is the build source of truth |
| Several containers share networks, volumes, or service configuration | Git-based Docker Compose | Compose owns the multi-service runtime definition |
| A CI system already publishes versioned images | Existing Docker image | Coolify deploys the published artifact instead of rebuilding source |
| The software is available in Coolify’s maintained template library | One-click Service | Coolify supplies an initial Compose stack |
If more than one row appears to fit, decide who should own the runtime configuration, whether you need one container or several, and where image building should occur.
Deployment method and build method are different choices
Coolify separates the input it receives from the way it turns that input into running containers. A deployment method can be a Git repository, a Dockerfile entered in the dashboard, a Compose definition in Git, or an already-built image. A build method is the strategy used to create images from Git source.
#1 Best Overall
That distinction matters because Nixpacks and Railpack are not alternative source types. They are build strategies inside the Git-repository path. Treating one of them as a separate deployment input can lead you to choose the wrong resource type and then look for settings that are available only after Git has been selected.
Git repository deployments
With the Git path, Coolify checks out the selected commit, determines the requested build strategy, prepares the required images, and updates the application container. The repository and commit provide a versioned source trail, so a deployment can be tied to a specific revision rather than to whatever files happen to be on a server.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesWhen Git is the best default
- Your team maintains application source in a repository.
- Deployments should follow commits or another Git event.
- You need repeatable revisions, webhooks, or pull-request previews.
- The project may change build strategy as it evolves.
Git is particularly useful when the repository is the canonical record of both source and build configuration. A selected commit gives you a clear point to inspect when a deployment fails or when you need to roll back.
Build strategies available inside the Git path
- Nixpacks or Railpack: use automatic framework and command detection when the project follows conventions that the selected builder can identify.
- Static: use this when the repository already contains finished website files and no image build is required beyond serving those files.
- Dockerfile: use this when the repository contains a custom Dockerfile that defines the image.
- Docker Compose: use this when the repository contains a Compose definition for multiple services or for runtime settings that should remain in Compose.
Automatic builders reduce setup for conventional projects, while a repository Dockerfile gives you explicit control over the image. Static deployment is appropriate only when the checked-out files are already the deployable site; it is not a substitute for a build process that your project still needs.
Git-specific trade-offs
Git gives you the strongest source traceability, but it also means Coolify must obtain the repository and perform the build. Build failures can therefore come from dependency installation, framework detection, commands, or the Dockerfile itself. If another pipeline already produces a tested image, rebuilding the source in Coolify may duplicate work; in that case, an existing-image deployment is usually cleaner.
Dockerfile without Git
The standalone Dockerfile path stores the Dockerfile entered in the Coolify dashboard, builds an image from its instructions, and creates the application container. It is a good fit for a small or experimental workload where the Dockerfile itself is the complete input.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The important limitation
A Dockerfile entered without Git cannot use COPY to read project files from a repository. If the image needs application source, package files, static assets, or any other build context that lives in Git, select the Git deployment path instead and let Coolify build from that repository.
Use this path when
- The Dockerfile is short, self-contained, and easy to maintain in the dashboard.
- You are testing an image recipe before moving it into source control.
- No repository checkout or external build context is required.
Once the Dockerfile becomes part of a larger project, storing it with the source in Git normally gives you better history, review, and reproducibility. The dashboard-entered version is convenient, but its contents are not represented by a repository commit unless you maintain that record separately.
Git-based Docker Compose deployments
Choose this method when the repository contains a Compose file and the application is really a group of cooperating containers. Coolify reads the definition, builds services that use build:, pulls services that use image:, and applies the result with Docker Compose.
Why Compose is the right abstraction
Compose is designed to express relationships that are awkward to manage as independent applications: shared networks, named volumes, service dependencies, ports, environment settings, and multiple containers released together. If those relationships are part of the project, keeping them in the Compose file makes the repository the operational source of truth.
What Compose ownership changes
For services and runtime settings defined by Compose, do not assume every standard Coolify Application setting can override the file. A dashboard change may not take effect when the Compose definition owns that value. Make the change in the repository’s Compose configuration, commit it, and deploy that revision.
This ownership rule is the main difference between a conventional Application and a Compose-based deployment. A conventional Application exposes more of its runtime configuration through the application resource; a Compose project expects the file to define the multi-service runtime.
Choose Compose when
- There are several containers that must be deployed as one system.
- Service-to-service networking or shared volumes are central to the design.
- The repository already treats the Compose file as its deployment contract.
- You want infrastructure changes reviewed alongside application changes.
Existing Docker image deployments
A Docker Image application pulls an image from a registry and applies the saved runtime configuration without building source code in Coolify. This is the natural choice when a separate CI system already tests and publishes the image.
Tags versus digests
You can specify a tag such as ghcr.io/example/api:1.4.0 or a SHA256 digest. A digest identifies immutable image content. A mutable tag such as latest can point to different content on a later deployment, even though the configuration still appears unchanged.
Use a versioned tag when your release process deliberately moves that tag to a new image and you want Coolify to follow it. Pin a digest when the exact image bytes must remain fixed for an audit, rollback, or reproducible release. The trade-off is operational: digest pinning improves determinism, while moving tags reduce the work needed to update the reference.
When this path is better than Git
- Your CI pipeline already builds, scans, tests, and publishes the image.
- The deployment server should only pull and run an approved artifact.
- The source repository is not needed by the runtime deployment.
Coolify still manages runtime configuration and container updates, but it is not responsible for compiling the source or assembling the image in this model.
One-click Services versus Applications
A Coolify Service launches software from a maintained Docker Compose template. The template supplies the initial Compose stack, and the Service runs that stack on one connected server.
Use a Service when the software you need already exists in Coolify’s template library and the supplied Compose configuration is an appropriate starting point. This avoids creating the stack manually and gives you a maintained baseline for the service.
Use an Application when you control the source code, Docker configuration, or image reference. Applications cover the Git, standalone Dockerfile, Git-based Compose, and existing-image paths described above. The distinction is ownership: a Service begins with Coolify’s template, while an Application begins with an artifact you or your build system maintain.
Where Coolify applications actually run
Coolify is a control plane for infrastructure. It stores configuration and coordinates actions, but Docker on each connected server runs the applications, databases, and services.
Self-hosted Coolify
In a self-hosted installation, you operate the Coolify instance and connect the servers that should run workloads. The control-plane machine and workload machine can be the same server or separate servers, depending on how you configure the infrastructure.
Coolify Cloud
With Coolify Cloud, the Coolify team operates the control plane. You still provide the servers where your workloads run and connect those servers to the control plane. Cloud hosting of the dashboard does not mean the application containers run inside the dashboard service.
Networking and incoming traffic
HTTP traffic goes to the reverse proxy on the workload server, not through the Coolify dashboard or API. The control plane instructs the server what to run; the server’s Docker environment and reverse proxy handle the actual container and request path.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What happens during a deployment
- Queue: Coolify accepts a manual action, Git event, deployment webhook, or API request and places the deployment in its execution flow.
- Resolve: It identifies the requested source revision, Dockerfile, Compose definition, or image reference.
- Build or pull: For source-based methods it builds the required images; for an existing-image deployment it pulls the referenced image.
- Apply configuration: Runtime settings and, where applicable, the Compose definition are rendered for the target server.
- Update containers: Docker replaces or starts the containers and the reverse proxy routes traffic to the resulting workload.
Deployment logs expose the selected revision, image operation, generated configuration, and container actions. When diagnosing a failure, identify which stage stopped instead of treating every error as an application-code problem.
Best Value
A practical selection procedure
- Identify the artifact you can reproduce. Is it repository source, one self-contained Dockerfile, a Compose file, or a published image?
- Count the runtime units. A single web process points toward Git, Dockerfile, or image deployment; several cooperating containers point toward Compose.
- Locate build ownership. If Coolify should build from source, use Git or the standalone Dockerfile. If CI already publishes the approved image, use the existing-image path.
- Choose the configuration owner. Keep multi-service wiring, volumes, and service settings in Compose when Compose is the project contract. Use Application settings when the resource itself should own runtime configuration.
- Check for a maintained template. If the desired software is already available as a suitable one-click Service and you do not need to maintain its source or image, the Service path can be the shortest route.
- Pin the release deliberately. Select a commit, versioned image tag, or digest according to the rollback and reproducibility you require.
- Connect the correct server. Confirm that the target workload server has Docker, network access, and the resources needed by the containers before triggering deployment.
Common mistakes and how to correct them
Choosing Nixpacks or Railpack as though it were a deployment input
These are build strategies within the Git path. Start with a Git repository, then choose the automatic builder if it matches the project.
Using a dashboard Dockerfile that needs repository files
A standalone Dockerfile has no Git checkout to provide a build context for COPY. Move the Dockerfile and required files into a repository and deploy through Git.
Expecting Application fields to override Compose
Compose-owned services and settings come from the Compose file. Edit that file, commit the change, and deploy the new revision instead of relying on a conflicting dashboard value.
Deploying latest when an immutable release is required
A mutable tag can resolve to different content later. Use a versioned tag or SHA256 digest when the deployed bytes must be known in advance.
Assuming Coolify hosts the workload itself
The control plane coordinates deployment; Docker on your connected server runs the containers. Check the workload server’s capacity, connectivity, and reverse-proxy routing when the application is unreachable.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Quick Recap
Checklist before you deploy
- The selected method matches the artifact your team actually maintains.
- The build owner is clear: Coolify, a Dockerfile, Compose, or external CI.
- The runtime topology is intentional: one container or a Compose-managed group.
- Compose-owned settings are edited in Compose rather than overridden elsewhere.
- The image reference is pinned to the level of mutability your release process permits.
- The target connected server is the server where Docker should run the workload.
- You know whether deployment will be manual, Git-triggered, webhook-driven, or API-driven.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
