Maintenance

Maintenance (System → Maintenance) holds the tools you need to look after the installation itself: housekeeping, backups, updates and moving to a bigger server. It has four tabs.

These tools keep working even if the main application has trouble loading. Only staff with Use cron, backups, updates and maintenance can open them.

The problem it solves

On shared hosting you often have no command line. Updating the script, taking a backup or clearing a stuck cache would normally mean asking your host. These tools let you do it from the browser.

1. App Core

At the top of every Maintenance tab there is a switch for maintenance mode. It takes the site offline for visitors with a "back soon" page, or brings it back. Use it during an update. Under it are small housekeeping actions:

ButtonWhat it does and when to use it
Refresh AppTells the server to reload the app's state. A gentle first thing to try.
Storage SymlinkRe-links the public storage folder so uploaded images and files show again. Try this if images are broken after a move.
Clear System CacheClears the application, config, route and view caches. Try this if a change does not show up.
Reboot SystemA full reset in one click: re-links storage, clears every cache and brings the app out of maintenance mode.
SitemapYour sitemap is always live at /sitemap.xml: every public page in each enabled language, published custom pages and the user guide. It updates by itself every hour, and /robots.txt points search engines to it. Open sitemap shows it; Refresh now rebuilds it straight away. Submit its address once in Google Search Console and Bing Webmaster Tools. If you put your own robots.txt or sitemap.xml file in public/, yours is used instead.

2. App Backup

A backup is a safe copy of your whole installation, so you can recover from a mistake or a bad update.

Restore overwrites everything. It replaces the current application and database with the backup. Anything added since is lost. Threadline asks you to confirm first. A database-only backup restores just the database, and so does any backup on a Docker install. If a restore cannot apply part of the database, it says so instead of reporting success.

3. App Update

Use this to install a new version you downloaded from CodeCanyon or ui-lib.com.

  1. Upload the update package. It must be a .zip file.
  2. Press Upload & Verify. Threadline checks that the package is a real, compatible Threadline update.
  3. Under Verified Packages, each package shows its version. Leave Back up the database first ticked and press install on the one you want. Progress is shown.
  4. When it finishes, check the Is everything on the new version? card: the website, database, queue worker and scheduler should all be up to date.
  5. Run the version seeder once, only after updating and only if the release notes say so, to add anything new the version needs.
  6. Open System → What's new to read what changed. After an update, the Owner dashboard shows a one-time notice that links there, and the installed version is always shown at the bottom of the Owner sidebar.

On a Docker or Dokploy server the app runs as several containers from one image, so uploading a zip here would update only one of them. The page shows rebuild steps instead: replace the source where your deploy tool builds from and redeploy (for example bash update.sh or docker compose up -d --build). Migrations and the storage link run by themselves on start. The version seeder still works there. A VPS where PHP runs directly, such as one managed with a control panel, updates from this page like shared hosting does. You can also update over SSH with php artisan threadline:update. Every method is explained in Updating Threadline.

4. Server (migration)

Threadline runs in one of two modes. Shared hosting mode searches your knowledge bases in MySQL. VPS mode searches them in Qdrant, a vector database that stays fast as they grow. This tab moves knowledge base search from one to the other on a server where PHP runs directly, such as one managed with a control panel. It does not change the queue, cache or sessions: those keep the settings in your .env.

  1. Install Qdrant on your server, then set QDRANT_URL (and QDRANT_API_KEY if you gave it one) in .env.
  2. Press Check readiness. It tells you whether Qdrant is reachable and whether Threadline can write to .env.
  3. Press Copy knowledge bases to Qdrant. It copies the search data of every workspace, with progress shown. Your site keeps answering from MySQL meanwhile.
  4. Press Switch to VPS mode. It first copies anything that changed since step 3, then starts using Qdrant. If a lot changed, it asks you to copy again.

Threadline refuses the switch while Qdrant is unreachable or before the copy has finished, so search never ends up empty.

Going back to shared hosting is instant: your knowledge bases' embeddings are always kept in MySQL, so nothing has to move back. You may also choose to delete the copy in Qdrant.

On a Docker or Dokploy install this tab only shows the current mode. There the mode is the SERVER line of the deployment's settings, and Qdrant is already part of the setup.

Common questions

Images are broken after I moved the site. Press Storage Symlink, then Clear System Cache.

The update stopped halfway. Do not panic. The site comes back online by itself. Run the update again with the same package. If a page still fails, restore the backup the update took first, then try again.

The site shows a "back soon" page for everyone. Maintenance mode is on. Turn it off here, or press Reboot System.