Updating Threadline

A new version arrives as a download from CodeCanyon or ui-lib.com, wherever you bought Threadline. How you apply it depends on how you installed. Find your row, then follow that section. Your data (database, uploaded files, your .env) is kept in every method.

You installed on	Update with
Shared hosting	Upload the ZIP in your browser
A VPS with a control panel, or PHP installed directly	Upload the ZIP in your browser, or run one command over SSH
A VPS with Docker Compose	`bash update.sh`
Dokploy (or Coolify)	Replace the files in your repository and press Deploy

Before you update

Download the latest version from CodeCanyon or ui-lib.com and read its changelog. If it says a step is needed, such as running the version seeder, do that after the update.
Keep your .env. Never replace it with the example file.
Pick a quiet time. The site is offline for a minute or two while files are replaced.
Updates add features and fix bugs but never go backwards. Threadline refuses a package older than the one installed.

Knowing a new version is out

Once a day Threadline asks the author's website whether a newer version exists. If one does, the Owner area shows a banner on every page and the App Update page names the version, with a link to what changed. It only tells you: nothing is downloaded or installed until you do it. The daily check needs the same cron job or scheduler the rest of Threadline uses (see Cron Setup), and it stays quiet if your server cannot reach the internet.

Upload the ZIP in your browser

For shared hosting and for any server where Threadline runs directly on the disk.

In the Owner area, open Maintenance and then App Update.
Click Update Application and choose the update ZIP (named like threadline-v1.2.0.zip). Large files upload in pieces, so a small PHP upload limit is not a problem.
The package is checked and listed under Verified Packages with its version. A label appears if it is older than, or the same as, what you have.
Leave Back up the database first ticked, then click Install. Keep the tab open until the progress bar finishes.
Look at the Is everything on the new version? card. See After the update.

The automatic backup saves the database only, and it is listed on the App Backup page. Your code can always be downloaded again; your data cannot.

Uploaded files are not in this backup. An update never deletes or replaces them: it only writes the files in the package, and the package has none in storage/app. If Storage is set to local, your documents, media and logos stay in storage/app on the server, so copy that folder yourself from time to time (or use S3 or R2) in case the server's disk fails or you move to another server.

If the update stops with a message that the web server cannot write to some files, the files belong to another user (often root, after an upload over SSH). Nothing was changed and the site is still online. Give the web server's user ownership and try again. The message names the exact command, for example:

chown -R www-data:www-data /var/www/threadline

Run one command over SSH

For a server where Threadline runs directly on the disk. It does the same checks and steps as the browser, with no upload limit. Upload the update ZIP to the server, then run it as the user that owns the Threadline files, not as root:

cd /var/www/threadline
sudo -u www-data php artisan threadline:update /path/to/threadline-v1.2.0.zip

On aaPanel the website user is www and each PHP version has its own program:

cd /www/wwwroot/desk.example.com
sudo -u www /www/server/php/84/bin/php artisan threadline:update /tmp/threadline-v1.2.0.zip

Option	What it does
`--no-backup`	Skips the automatic database backup.
`--force`	Does not ask for confirmation. Use it in scripts.
`--allow-downgrade`	Installs a package older than the current version. Only use it if you also restore a matching database backup.

VPS with Docker Compose

Docker builds the code into an image, so a ZIP cannot be applied from the browser. The Update page shows these steps instead.

Unpack the new version over the folder you installed from, leaving out its .env so yours is kept, for example:
```
unzip -o threadline-v1.2.0.zip -x .env -d /opt/threadline
```
From that folder, run:
```
bash update.sh
```

The script saves a database dump into a backups folder, rebuilds the image, restarts every container, waits for the app to answer and prints the running version. It prints each command before running it. Useful options:

`bash update.sh --dry-run`	Shows what it would do and changes nothing.
`bash update.sh --no-backup`	Skips the database dump.

Prefer to run it by hand? These are the same steps:

docker compose exec -T mysql sh -c 'mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" "$MYSQL_DATABASE"' > backup.sql
docker compose -f docker-compose.yml -f docker-compose.ports.yml up -d --build

Database changes are applied automatically when the app container starts. Each release names the Qdrant version it was tested with in docker-compose.yml. Qdrant can only be upgraded one minor version at a time, so do not edit that line to jump several versions.

Never run docker compose down -v. The -v deletes the database and your uploaded files. docker compose down without it is safe.

Dokploy (or Coolify)

Replace the files in the Git repository Dokploy deploys from with the new version. Keep your own settings in Dokploy's Environment tab, not in the repository.
Commit and push.
In Dokploy, press Deploy (it deploys by itself if you turned on auto deploy).

Dokploy rebuilds all containers from the new files, and database changes are applied on start. Make sure your database backups are current before you deploy. See Install: VPS (Dokploy).

After the update

The App Update page has a card called Is everything on the new version?. It compares four things:

Row	Healthy when
Website	Shows the version you just installed.
Database	Says Up to date, with no updates waiting.
Queue worker	Shows the same version within about a minute: the restarted worker reports while it waits for work. No report yet for longer means the worker did not start again; check Supervisor (or your Docker worker).
Scheduler	Shows the same version.

Running old code means a background process started before the update and has not restarted. Messages would be handled by the old version. On Docker, redeploy so every container restarts. On a server, restart your queue worker (for example supervisorctl restart all). The browser update and threadline:update already tell workers to restart, so a worker under supervisor or systemd comes back by itself within moments.

If something goes wrong

What you see	What to do
The web server cannot write to some files	Give the web server's user ownership of the Threadline folder (see above), then try again.
The package is older than the installed version	Download the latest release from CodeCanyon or ui-lib.com instead.
The database could not be backed up	Fix the reason shown (often disk space or a PHP memory limit). Or back it up yourself and update without the backup option.
The update failed halfway	The site comes back online by itself. Run the update again with the same package. If a page still fails, restore the database from App Backup.
The progress bar stops, or the page says it lost contact with the server, and the site shows a "back soon" page	Something restarted PHP or the connection dropped in the middle (a server's automatic security updates can do this). Nothing is damaged. Wait a minute, open Maintenance → App Update (it stays reachable while the site is offline), and press Retry on the package. It starts again from the first file, which is safe. If you have SSH, running `sudo -u SITE_USER php artisan threadline:update /path/to/package.zip` does the same.
Queue worker or scheduler shows Running old code	Restart it, as described above.

Restoring a backup returns the database to how it was. Restore a database-only backup only together with the code version it was taken with. More in Troubleshooting & FAQ and Maintenance.

← Cron Setup AI Provider Setup →