Skip to main content

Upgrading Mixpost Pro to v7 from v6

Backup your database first

Always back up your database before starting the upgrade. If something goes wrong, you will need it to restore your previous state.

This guide walks you through upgrading Mixpost Pro from v6 to v7. Choose the path that matches your installation method: Docker or PHP (manual / Laravel package).

Breaking change: Mixpost now runs at the root of your domain

v7 changes the default value of MIXPOST_CORE_PATH from mixpost to empty. Read Mixpost now runs at the root of your domain before you upgrade — it affects your dashboard URL and the Redirect URIs registered with your social provider apps.

Mixpost now runs at the root of your domain​

From v7 the MIXPOST_CORE_PATH prefix is opt-in: it is empty by default and Mixpost is served from the root of the domain.

Are you affected?

Only if you never set MIXPOST_CORE_PATH yourself. If your .env already sets it explicitly, your paths do not change at all — the value you set keeps working exactly as before.

What changes​

Dashboard/<MIXPOST_CORE_PATH>/
API/<MIXPOST_CORE_PATH>/api/*/api/*
MCP server/<MIXPOST_CORE_PATH>/mcp/mcp
OAuth callback/<MIXPOST_CORE_PATH>/callback/{provider}/callback/{provider}
Engagement webhook/<MIXPOST_CORE_PATH>/inbox-webhook/{provider}/inbox-webhook/{provider}
Uninstall callback/<MIXPOST_CORE_PATH>/uninstall-callback/{provider}/uninstall-callback/{provider}
Public pages/pages/*/pages/* — unchanged

<MIXPOST_CORE_PATH> is the prefix your instance uses today — mixpost unless you set a different one. The After column shows where each route lands once MIXPOST_CORE_PATH is empty.

Public pages, manifest.json and the Bluesky OAuth metadata endpoints are registered outside the core path and are not affected.

The callback URLs are the risky part

A moved dashboard is obvious — you will see it the first time you open Mixpost. A moved callback URL is silent: already-connected accounts keep publishing, but the Redirect URI registered with each social provider app no longer matches, so reconnecting an account or connecting a new one fails. The same applies to the Engagement webhook callbacks.

Decide which of the three options below you want before you upgrade.

Option A — keep everything exactly as it is (recommended)​

The safest path for an existing installation: pin the previous value and nothing changes. Use mixpost if you never changed it, or the custom prefix you chose at install time.

MIXPOST_CORE_PATH=mixpost

Your dashboard stays at https://example.com/mixpost, and every Redirect URI already registered with your social provider apps keeps working. There is nothing else to do.

Option B — dashboard at the root, callbacks unchanged​

v7 adds MIXPOST_CALLBACK_PATH, a prefix that applies only to the callback routes.

It exists because a callback URL is not merely a setting on your side. Your social provider apps have already been authorized against those exact URLs, and several platforms tie their app review to them — changing a callback URL there means submitting for approval again and waiting for it, while account connections stay broken in the meantime.

This option moves the dashboard to the root while leaving every registered callback URL exactly where it is:

MIXPOST_CORE_PATH=
MIXPOST_CALLBACK_PATH=mixpost

The dashboard is served from https://example.com, while /mixpost/callback/{provider}, /mixpost/inbox-webhook/{provider} and /mixpost/uninstall-callback/{provider} stay exactly where your provider apps expect them.

Leave MIXPOST_CALLBACK_PATH empty to have the callback routes follow MIXPOST_CORE_PATH, which is the default.

Replaces FORCE_CORE_PATH_CALLBACK_TO_NATIVE

MIXPOST_CALLBACK_PATH supersedes FORCE_CORE_PATH_CALLBACK_TO_NATIVE, which is now deprecated. The old variable still works — setting it to true is equivalent to MIXPOST_CALLBACK_PATH=mixpost — but MIXPOST_CALLBACK_PATH lets you choose any prefix, so prefer it in new configurations.

Option C — move to the root​

Leave both MIXPOST_CORE_PATH and MIXPOST_CALLBACK_PATH empty. Your dashboard moves to https://example.com, and after upgrading you must update, for every social provider app you use:

  • the Redirect URI — from /<MIXPOST_CORE_PATH>/callback/{provider} to /callback/{provider}
  • the Engagement webhook callback URL, if you use Engagement — from /<MIXPOST_CORE_PATH>/inbox-webhook/{provider} to /inbox-webhook/{provider}

Also update any API client or MCP client that has the old base URL hardcoded. The exact Redirect URI for each provider is always shown in that provider's service form inside Mixpost, so you can copy it from there after the upgrade.

Installed inside an existing Laravel application?​

Keep a prefix. With an empty core path Mixpost registers its routes at the root of your application, including / itself. Routes defined by your own application are registered after the package's, so on a conflicting URI your route wins and Mixpost's is silently shadowed — a route that simply stops resolving, with no error at boot.

Set MIXPOST_CORE_PATH to a prefix of your choice (mixpost keeps your current URLs) and Mixpost stays isolated from your own routes.

Upgrade Using Docker​

  1. Open the .env file next to your docker-compose.yml and apply the option you picked in Mixpost now runs at the root of your domain — set MIXPOST_CORE_PATH, and MIXPOST_CALLBACK_PATH too if your option uses it, to the values that option lists.
warning

Mixpost rebuilds the .env inside the container from this file on every start, so anything you leave out falls back to the new defaults. An absent MIXPOST_CORE_PATH is exactly what moves your paths to the root.

  1. Navigate to the folder containing your docker-compose.yml.
  2. Run the following commands:
# Pull the latest version
docker compose pull

# Stop and remove the old container
docker compose down

# Start a new container
docker compose up -d
Rolling back

If something goes wrong, revert to the v6 image tag (inovector/mixpost-pro-team:v6) in your docker-compose.yml, restore your database backup, and run docker compose up -d again.

Upgrade in a PHP Environment​

Choose your installation type below.

Manual Installation (PHP)​

If you installed Mixpost Pro using the manual installation method, use the automatic upgrade script:

curl -fsSL https://raw.githubusercontent.com/inovector/MixpostProTeamApp/main/scripts/upgrade/upgrade_v7.sh | bash

The script handles dependency updates, migrations, asset publishing, and cache clearing.

Before or after running it, apply the option you picked in Mixpost now runs at the root of your domain to your .env — set MIXPOST_CORE_PATH, and MIXPOST_CALLBACK_PATH too if your option uses it. If MIXPOST_CORE_PATH is absent from your .env, Mixpost is served from the root.

Laravel Package​

If Mixpost Pro is installed within an existing Laravel application, follow these steps.

Laravel 12+ required

Mixpost Pro v7 requires Laravel 12 or 13. If your application runs Laravel 10 or 11, upgrade Laravel first before proceeding.

Step 1. Update dependencies​

composer require inovector/mixpost-pro-team "^7.0" -W

Step 2. Run database migrations​

php artisan mixpost:upgrade-database --force

The command runs the upgrade migrations shipped with the package. Executed migrations are recorded in the migrations table, so it is safe to run more than once.

Step 3. Publish assets​

php artisan mixpost:publish-assets --force=true

Step 4. Update config​

If you previously published the Mixpost config file, re-publish it so the new keys are available:

php artisan vendor:publish --tag=mixpost-config --force

v7 changes the following config keys:

  • core_path (MIXPOST_CORE_PATH) — the default changed from mixpost to empty. Re-publishing the config applies the new default, so set MIXPOST_CORE_PATH in your .env before you re-publish — see Installed inside an existing Laravel application?.
  • callback_path (MIXPOST_CALLBACK_PATH, new, default empty) — a prefix applied only to the callback routes. Empty means they follow core_path.
  • force_core_path_callback_to_native (FORCE_CORE_PATH_CALLBACK_TO_NATIVE) — deprecated in favour of callback_path, still honoured.

See the environment variables reference for the full list.

Step 5. Raise retry_after on the queue connection​

This step is specific to a Laravel package installation. You wrote the mixpost-redis connection yourself when you installed Mixpost, so nothing updates it for you — Docker and manual installations get the corrected value with the rest of the app files.

Open config/queue.php and raise retry_after on the mixpost-redis connection to 960:

'mixpost-redis' => [
    'driver' => 'redis',
    'connection' => 'default',
    'queue' => env('REDIS_QUEUE', 'default'),
    'retry_after' => 960,
    'block_for' => null,
],
Why this matters

retry_after must stay above the longest supervisor timeout, which is 900 seconds. The value published with earlier versions — 11 * 60, that is 660 — sits below it on the growth and scale tiers: Redis considers a job abandoned while its worker is still running and hands it to a second one, so a post gets published twice and an analytics import runs twice.

v7 adds a check for this to the System Status page, which reports the value your connection needs for the tier you run. Restart Horizon after the change: php artisan horizon:terminate.

Step 6. Clear the cache​

php artisan optimize:clear --except cache
php artisan mixpost:clear-services-cache
php artisan mixpost:clear-settings-cache

Step 7. Optimize application​

php artisan optimize --except cache

Step 8. Restart Reverb​

info

Only required if reverb is your BROADCAST_DRIVER. Skip this step otherwise.

php artisan reverb:restart

Step 9. Verify your routes​

Confirm Mixpost is registered where you expect, and that none of its routes are shadowed by your application's own:

php artisan route:list --name=mixpost

On this page