The routine
Pull the new version, then run the same steps you already run on a deploy:
- Rebuild dependencies and assets, and re-run the optimization commands
- Apply migrations with
php artisan migrate --force
- Restart the queue workers so they pick up the new code —
php artisan horizon:terminate lets Supervisor bring them back
On Docker, Common production commands has the container equivalents.
Back the database up before migrate --force. Migrations run unattended and some of them rewrite data, not just schema. A dump you can restore is the only reliable way back.
Release notes that need attention
Most upgrades need nothing beyond the routine above. The ones below change data or defaults, so read them if you are crossing that version.
Multiple social accounts per network
This release adds a database constraint that a workspace cannot hold the same identity twice on the same platform.
Why it matters: earlier versions could store the same account more than once — the per-network guard was skipped on self-hosted installs, and Pinterest created a fresh row on every connect. Duplicates like that would block the new constraint, so the migration merges them first.
For each duplicated identity it keeps the most recently created account, moves that account’s scheduled posts and automation targets onto the survivor, and deletes the rest.
Merging can leave a post aimed at the same account twice, which would publish it twice. Those repeats are collapsed:
- If the post has not published there yet, one target survives — the one you had enabled, if any
- If it has already published there, every unpublished repeat is removed, since the content has gone out
Targets that already published are never deleted or altered. They record what went out, and hold the id the platform needs to manage that post later.
This is one-way. Rolling the migration back drops the constraint but does not bring the merged rows back.
Every merge is written to your log at warning level with enough detail to reconstruct it:
Want to know what it will do before it does it? Restore a copy of your production database somewhere disposable, run php artisan migrate --force against the copy, and read those log lines. If nothing is logged, you have no duplicates and the migration is a no-op.
ALLOW_MULTIPLE_SOCIAL_ACCOUNTS decides whether a workspace may connect several accounts on one network. You do not have to set it — when it is missing it follows SELF_HOSTED, so an existing self-hosted install keeps the behaviour it had.
