1.4.0 Upgrade

[tep1997]

What is the recommended upgrade path to convert to the new 1.4.0 release? The standard update commands break the frontend as you mentioned in the update release. How then do we upgrade, or do we start from scratch?

[adminsyspro]

Hi @tep1997, sorry for the friction on this one.

Short answer: 1.4.0 is a clean install on top of a fresh Postgres database. There is no in-place migration from a 1.3.x SQLite install.

Why we went this way. We seriously considered keeping both backends side by side (Prisma talking to SQLite and Postgres) but carrying two database adapters means doubling every Prisma migration, every raw query we tune for vDC quotas / IPAM / reports, every test fixture, every CI matrix. SQLite was already where we hit lock contention as soon as multi-tenant workloads, vDC quotas, replication metadata and the report generator started running concurrently.

For where the product is heading next (HA via Postgres streaming replication, a shared cluster store between frontend and orchestrator, cross-tenant JSONB aggregations), Postgres is the right substrate. A maintained SQLite branch on top of that would slow every future release for everyone, including you.

Recommended upgrade path:

1. Take note of what's in your current install: Proxmox / PBS connections (URL + API token), local user accounts, branding, alert rules. None of this carries over automatically.
2. Stop the old stack:

   cd /opt/proxcenter && docker compose down
   

3. Optional safety net, move the old SQLite file aside instead of deleting it:

   mv /opt/proxcenter/data/proxcenter.db /opt/proxcenter/data/proxcenter.db.pre-1.4.0
   

4. Re-run the installer, which now pulls the new docker-compose.community.yml, creates the postgres_data volume, generates a Postgres password and brings the stack up:

   curl -fsSL https://get.proxcenter.io/community | sudo bash
   

5. Open the UI, go through the first-boot setup wizard (create the admin account), then re-add your Proxmox / PBS connections.

What you do not need to redo: the VMs and CTs themselves live on Proxmox, so the inventory scan picks them up automatically once a connection is re-added. Backups on PBS are unaffected too, you just re-bind the PBS connection.

What you do lose: audit history, in-app task / event history, in-app alert rules. If audit retention matters for you, export it from the 1.3.x UI before stopping the stack.

We'll add a proper "Upgrading from 1.3.x" section to the repo so this isn't only in a discussion thread. Thanks for flagging it.

[tep1997]

Ok, makes sense. Thanks for the reply.

I used a docker compose file to install originally if I'm not mistaken. Is that still an option?

[adminsyspro]

Yep, compose-only is still fully supported, the proxcenter.io/install/community script is just a thin wrapper around it. If you'd rather drive it yourself:

1. Grab the two files from the repo:

   • docker-compose.community.yml
   • .env.example → copy to .env

2. Fill in .env. The three required ones for Community are:

   APP_SECRET=$(openssl rand -base64 32)
   NEXTAUTH_SECRET=$(openssl rand -base64 32)
   POSTGRES_PASSWORD=<something you pick>
   

   Also set NEXTAUTH_URL / APP_URL to whatever you reach the UI on.

3. The compose file declares proxcenter_data and postgres_data as external volumes, so create them once before bringing the stack up (the installer script does this for you, that's the only meaningful thing it adds):

   docker volume create proxcenter_data
   docker volume create postgres_data
   

4. Then:

   docker compose -f docker-compose.community.yml --env-file .env up -d
   

5. First boot, the frontend container applies Prisma migrations against the empty Postgres, then the setup wizard takes over on :3000.

One thing to watch: the old 1.3.x compose pointed at a SQLite file under proxcenter_data. If you're reusing that volume, it'll still hold the old proxcenter.db and the frontend will simply ignore it (Postgres is the only adapter now). Safer to either move it aside as I mentioned above, or create a fresh proxcenter_data volume.

(Edit: fixed the installer URL, it's proxcenter.io/install/community, not the get. subdomain I had above.)

[tep1997]

Ok, after carefully considering your post, I decided to scrap my current setup and just start from scratch using the script. The curl command wouldn't work for some reason (could not resolve host error). I manually copied the script and now have a working instance of the new architecture.

Thanks for all the work!

[adminsyspro]

Glad you got it running, and thanks for sticking with it!

Quick follow-up on the could not resolve host you hit on the curl command, if you don't mind. Do you remember which URL exactly failed, and was it reproducible or a one-off? Just want to make sure the install one-liner actually works for the next person landing on the README.

[tep1997]

This is what I ran:

curl -fsSL https://get.proxcenter.io/community | sudo bash

Error:

I ran it on multiple hosts with same results. Looks like perhaps the subdomain doesn't resolve, but the root does:

[adminsyspro]

Thanks for the screenshot, that nails it. The get.proxcenter.io subdomain doesn't exist, it was a typo I introduced in my first reply on this thread. The canonical install URL is the one already shown in the README:

curl -fsSL https://proxcenter.io/install/community | sudo bash

Two of the install scripts still carried the wrong URL in their header comment / upgrade hint (install-community.sh and install-enterprise.sh), fixed in b0d1f21c so the next person copy-pasting from those files lands on the right host. Thanks again for following up on it.

[tep1997]

Finally, what is the proper way to update a non-docker install that was setup using the script?

[adminsyspro]

The install script you ran is actually a Docker install under the hood. It installs Docker Engine if it isn't already there, writes docker-compose.yml + .env into /opt/proxcenter, creates the proxcenter_data and postgres_data volumes, and brings the containers up. So even though you didn't type docker yourself, that's what's running on your host.

You can confirm with:

docker ps

You should see proxcenter-frontend and proxcenter-postgres. If that's the case, the update is just:

cd /opt/proxcenter
docker compose pull
docker compose up -d

That re-pulls ghcr.io/adminsyspro/proxcenter-frontend:latest, recreates the container, and the entrypoint applies any new Prisma migrations against your existing Postgres volume on the way up. Your .env, your data and your Proxmox / PBS connections are all preserved.

If on the other hand you genuinely have a non-Docker setup (Node running directly under systemd against a native Postgres), that isn't a path we ship today. The only supported install is the Docker one.

[tep1997]

My apologies for fouling the waters. When I said 'non-docker', I guess I didn't realize it was running Docker behind the scenes. All good now with the update commands you gave.

Thank you!