coolifyv32Go

coolfymigrater

One-shot migration tool that hands a running Coolify v3 install over to coolifygo on the same host. Reads v3's SQLite database directly, decrypts its secrets with v3's COOLIFY_SECRET_KEY, inserts equivalent rows into coolifygo's Postgres, takes over every workload container (apps + DBs), upgrades the host Docker engine, and finally wipes the v3 stack.

Quickstart — one command

On the v3 host:

curl -fsSL https://raw.githubusercontent.com/annihilatorrrr/coolifyv32Go/main/install.sh | sudo bash

That wrapper does the whole thing end to end:

1. Installs Go if missing or older than required (Go 1.26.5+) — never downgrades a newer host toolchain
2. go installs this migrater from source
3. Freezes v3 — stops coolify + coolify-fluentbit, releasing port 3000 and quiescing SQLite
4. Upgrades the host's Docker engine (always-on — v3 ships with an old version; safe here because v3 is frozen and coolifygo isn't up yet)
5. Installs coolifygo via gocoolify/install.sh (skipped if already running) — port 3000 is now free and Docker is modern
6. Runs --phase=pre-docker — discover, extract SQLite, decrypt, plan, insert into coolifygo's Postgres
7. Runs --phase=post-docker — takes over every v3 workload container, then wipes v3 completely

No manual flags required — DSN + encryption key are sourced from /data/coolifygo/.env.

Install

The migrater is a single Go binary. You can install it the same way install.sh does, or build it from source.

# Install the published binary onto PATH (what install.sh runs internally)
GOBIN=/usr/local/bin go install github.com/annihilatorrrr/coolifyv32Go@latest

# …or build from a checkout of this repo
git clone https://github.com/annihilatorrrr/coolifyv32Go
cd coolifyv32Go
go build -o bin/coolfymigrater .      # binary at ./bin/coolfymigrater

Requires Go 1.26.5+ and a local Docker socket. No CGO — the SQLite reader is pure Go (modernc.org/sqlite).

Usage

coolfymigrater [flags]

The two connection flags are the only required inputs. Everything about the v3 side (COOLIFY_SECRET_KEY, the prod.db path, the workload containers) is auto-detected from the running coolify container — you never supply those.

Where do the DSN and key come from?

You don't invent them — coolifygo writes them to its own env file when it is installed, at /data/coolifygo/.env:

DATABASE_URL=postgres://coolifygo:...@coolifygo-postgres:5432/coolifygo
DATA_ENCRYPTION_KEY=<base64 of 32 random bytes>

• Via install.sh (the one-command path): you do nothing. The wrapper sources /data/coolifygo/.env for you (load_coolifygo_env) and passes both values through — no flags, no exports.

• Running the binary by hand: source that same file first so the two flags pick the values up from the environment:

  set -a; . /data/coolifygo/.env; set +a   # exports DATABASE_URL + DATA_ENCRYPTION_KEY
  coolfymigrater --yes
  

  or point at it explicitly without exporting anything:

  coolfymigrater \
    --coolifygo-dsn="$(grep '^DATABASE_URL='        /data/coolifygo/.env | cut -d= -f2-)" \
    --coolifygo-key="$(grep '^DATA_ENCRYPTION_KEY=' /data/coolifygo/.env | cut -d= -f2-)"
  

(The file path is configurable in install.sh via COOLIFYGO_ENV.)

Flags

Environment variables

Examples

# 1. Dry run — see exactly what would be migrated, change nothing.
coolfymigrater --coolifygo-dsn=$DATABASE_URL --coolifygo-key=$DATA_ENCRYPTION_KEY --dry-run

# 2. Full single-shot migration, no prompts (env vars already exported).
coolfymigrater --yes

# 3. Migrate the data + take over containers, but LEAVE v3 running
#    (nothing is wiped — useful to validate coolifygo before committing).
coolfymigrater --yes --no-teardown

# 4. Provide v3 secrets explicitly if auto-detection can't reach the container.
coolfymigrater \
  --v3-secret-key=base64:xxxxxxxx... \
  --v3-sqlite=/data/coolify/source/prod.db

# 5. Phase-split run by hand (what install.sh does around a Docker upgrade).
coolfymigrater --phase=pre-docker  --state-file=/tmp/mig.json --yes
#   … upgrade Docker / restart the daemon here …
coolfymigrater --phase=post-docker --state-file=/tmp/mig.json --yes

The connection flags (--coolifygo-dsn / --coolifygo-key) are required in every phase, including post-docker — takeover reopens Postgres to write the real container ids back onto the migrated rows.

install.sh overrides

The wrapper is driven entirely by environment variables, so you can pin versions or point it at forks without editing the script:

MIGRATER_REF=v1.2.3 sudo -E bash install.sh

Build & test

go build ./...                    # compile everything
go build -o bin/coolfymigrater .  # build the CLI binary
go vet ./...
go test ./...

Scope

Built for the narrow shape the operator described:

• v3 manages Dockerfile-built apps only (other build packs error out).
• v3 manages PostgreSQL + Redis databases only (MySQL / Mongo error out).
• No persistent storage on application containers.
• GitHub App git sources only — other git-source auth types are skipped (multiple GitHub App sources are supported).
• v3 runs on the same host as coolifygo (local Docker socket).

Everything else (services, FQDN/Traefik/SSL, teams, PR previews, remote destinations, Storages) is intentionally skipped.

Phases

1. discover — inspect the local coolify container for the secret key and container metadata; list every workload on the coolify-infra network.
2. connect coolifygo postgres — verify DSN + key + that a type=local server row already exists (created by coolifygo's EnsureLocalServer).
3. freeze — stop coolify and coolify-fluentbit so v3's SQLite is in a consistent state.
4. extract + read — docker cp /app/db/prod.db out of the already-frozen coolify container (no restart needed — docker cp works on stopped containers and the file is consistent because v3 is quiesced). Opens the copy via modernc.org/sqlite, decrypts every secret column with AES-256-CTR keyed by COOLIFY_SECRET_KEY. Temp file is cleaned up after the read.
5. plan — map v3 entities onto coolifygo row shapes. Validates that buildPacks and DB types are in scope.
6. insert — one Postgres transaction writes git_sources → applications → databases. Rollback on any failure leaves coolifygo untouched.
7. takeover — apps are recreated as coolifygo-<slug>-<id8> on the coolifygo bridge network with the existing image + env + host port binding + coolifygo's coolifygo.managed label. Databases stop, get their data volume copied (not moved) to coolifygo-db-<id8> via a one-shot alpine:3 container, then start fresh as coolifygo-db-<id8> with coolifygo's canonical image (postgres:<v>-alpine / redis:<v>-alpine), env, healthcheck, and network. After each recreate the real new container id + status are written back onto the coolifygo row.
8. teardown — stop+remove every v3 stack container (coolify, coolify-fluentbit, coolify-proxy, coolify-haproxy); drop the seven v3 infra volumes (coolify-db, coolify-logs, coolify-local-backup, coolify-ssl-certs, two letsencrypt volumes, and the optional coolify-pgdb); reclaim each copied-from database source volume (the originals takeover copied out of — guarded: never touches a coolifygo- volume, force=false so an in-use one is reported, not destroyed); prune coollabsio/coolify, ghcr.io/coollabsio/coolify, and ghcr.io/coollabsio/fluent-bit images plus the migrater's own alpine:3 copy-helper (only if unused); remove the coolify-infra network; and clean host paths (/data/coolify, /var/lib/coolify, /etc/cron.d/coolify-default, /usr/local/bin/coolify). On a completed post-docker run the migrater also removes its own state file and the now-empty state directory.

What gets copied

What gets thrown away

• v3 management containers (coolify, coolify-fluentbit, coolify-proxy, coolify-haproxy) + their infra volumes + the coolify-infra network.
• The original v3 database source volumes — reclaimed after their contents were copied into the new coolifygo-db-<id8> volumes.
• v3 host paths (/data/coolify, /var/lib/coolify, the systemd unit hint binary /usr/local/bin/coolify, the /etc/cron.d/coolify-default cron).
• v3 Traefik / Let's Encrypt state (SSL is out of scope in coolifygo).
• v3 backup volumes (coolifygo runs its own backup pipeline; old archives are not migrated).
• coollabsio/* + ghcr.io/coollabsio/* images, and the migrater's own alpine:3 copy-helper (only when no other container still uses it).

Safety

• Port conflict detection at plan time: the migrater checks for duplicate host ports within the migration batch and against resources already in coolifygo's database. Bails with a descriptive error before any change.
• Inserts run inside a single Postgres transaction. Rollback on any failure leaves coolifygo in its pre-migration state.
• Container takeover begins only after the transaction commits. A failed takeover leaves a partial state in coolifygo but never destroys v3's data volumes (those are dropped by the teardown phase, gated by a confirm prompt unless --yes is passed).
• --dry-run prints the full plan and exits before any change.

Re-runs

• Post-docker phase can be resumed from the saved state file (/var/lib/coolfymigrater/state.json by default). stopAndRemove tolerates containers that were already cleaned up on a prior attempt, so an interrupted takeover can be picked up where it left off.
• Pre-docker phase is not idempotent — coolifygo's schema has no unique constraint on names, so re-inserting would create duplicate rows. Drop coolifygo's database (greenfield design) before re-running pre-docker from scratch.
• A fully successful post-docker run deletes the state file so a stale resume can't confuse a future invocation.