Skip to main content

Upgrading Mixpost Enterprise to v8 from v7

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 Enterprise from v7 to v8. 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

v8 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, the Redirect URIs registered with your social provider apps, and the webhook URL registered with your payment provider.

Mixpost now runs at the root of your domain​

From v8 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>/
Enterprise console/<MIXPOST_CORE_PATH>/enterprise/enterprise
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}
Payment webhook/<MIXPOST_CORE_PATH>/payment-webhook/payment-webhook
Invitation links/<MIXPOST_CORE_PATH>/invitation/{invitation}/invitation/{invitation}
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 webhook URLs are the risky part

A moved dashboard is obvious — you will see it the first time you open Mixpost. A moved webhook URL is silent:

  • Social provider callbacks — already-connected accounts keep publishing, but the Redirect URI registered with each provider app no longer matches, so reconnecting an account or connecting a new one fails. The same applies to the Engagement webhook callbacks.
  • The payment webhook — Stripe, Paddle or Paystack keep posting to the old URL and get a 404. Subscription events stop being recorded, so plan changes, renewals and cancellations silently stop reaching Mixpost.

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 and webhook URL already registered with your social provider and payment apps keeps working. There is nothing else to do.

Option B — dashboard at the root, callbacks unchanged​

v8 adds MIXPOST_CALLBACK_PATH, a prefix that applies only to the callback routes — the social provider callbacks and the payment webhook.

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 URL registered with a third party 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}, /mixpost/uninstall-callback/{provider} and /mixpost/payment-webhook stay exactly where your social provider and payment provider apps expect them.

Nothing has to be reconfigured on any third-party dashboard with this option.

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}

You must also update the payment webhook — see Update the payment webhook URL — and 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.

Update the payment webhook URL​

Required with Option C only. With Option A nothing moves, and with Option B the payment webhook keeps its prefix along with the social callbacks.

Open your payment provider's dashboard and change the endpoint URL to the new path:

https://example.com/payment-webhook

The exact steps for each provider are in their setup guides — Stripe, Paddle Billing, Paddle and Paystack.

tip

Update the endpoint immediately after the upgrade and send a test event from the provider's dashboard. Until you do, subscription lifecycle events are lost — they are not replayed once the URL is corrected, unless your provider offers a manual redelivery.

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 v7 image tag (inovector/mixpost-enterprise:v7) 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 Enterprise using the manual installation method, use the automatic upgrade script:

curl -fsSL https://raw.githubusercontent.com/inovector/MixpostEnterpriseApp/main/scripts/upgrade/upgrade_v8.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 Enterprise is installed within an existing Laravel application, follow these steps.

Laravel 12+ required

Mixpost Enterprise v8 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-enterprise "^8.0" -W
tip

This also upgrades the bundled inovector/mixpost-pro-team package to v7. The -W (--with-all-dependencies) flag lets Composer resolve that automatically.

Step 2. Run database migrations​

php artisan mixpost:upgrade-database --force
php artisan mixpost-enterprise:upgrade-database --force

The commands run the upgrade migrations shipped with each package. Executed migrations are recorded in the migrations table, so they are safe to run more than once.

Step 3. Publish assets​

php artisan mixpost:publish-assets --force=true
php artisan mixpost-enterprise: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

v8 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: the social provider callbacks and the payment webhook. 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.

v8 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