- Push the code to GitHub (GitHub Desktop is the working method here - see the note on zsh below).
- In Coolify, create or select the Application.
- Use a Dockerfile-based build, not Nixpacks. Nixpacks' auto-detection has repeatedly failed on this setup's frameworks. A Dockerfile is the reliable path.
- For static multi-file sites (like the Wegweiser tools), every file needs its own explicit
COPY line in the Dockerfile - nginx only serves what the Dockerfile actually places into the image. Adding a new HTML file later? Add its COPY line too, or it silently won't be served.
- Deploy, then check the build log for errors before assuming it worked.
¶ Custom domains
- For a normal Application, the domain field is on the app's own settings page - straightforward.
- For a Docker Compose service (one-click installs like Wiki.js, or anything with multiple containers), this is NOT exposed the same way. See the dedicated page: Docker Compose Services & Custom Domains.
If a site uses output: 'hybrid' with the @astrojs/node adapter (needed when most routes are static but one, like /api/contact, needs to run server-side) - make sure the adapter is set to standalone mode, not middleware, for it to run correctly as its own container.
- Nixpacks vs Dockerfile: default to Dockerfile from the start for anything beyond a trivial static site. Switching later after a failed Nixpacks build wastes a debugging cycle.
- Copy-pasting into a terminal over zsh can corrupt heredocs and multi-line pastes. For pushing files/folders to GitHub, the GitHub web UI's drag-and-drop (a whole folder at once, not loose files) or the GitHub Desktop app are the reliable alternatives - avoid multi-line paste-heavy terminal workflows for this.
- Always check the build log, not just the green "running" status - a container can come up "healthy" on a stale image if a build silently failed and Coolify fell back to the last successful one.