Upgrading

🚧

If you run into any issues upgrading...

Please check the Common Issues > Installation/Upgrading Issues section which provides solutions for commonly encountered installation / upgrading problems.

📘

Note:

When available, please use the more detailed upgrade instructions for specific versions, available in the sidenav, and be sure to check out the release notes for your specific upgrade version.

Always backup your database and configuration files before upgrading. We try very hard to make sure that all database changes are non-destructive, but you should always backup beforehand anyway. You will never regret backing up your database. You may regret not doing so, so it’s just better to get into the habit.

Upgrading via Git

If you installed Snipe-IT via Git (which is our recommended method - seriously, we really, really recommend it), updating Snipe-IT should be pretty straightforward. Simply pull down the newest release (using git pull) and run whatever commands the release notes specify. Your configuration won’t be overwritten, since the .env file isn't checked into version control.

In Snipe-IT v4.1.3 and higher, you can try the one-step upgrade by running:

php upgrade.php

from your Snipe-IT project root.

That will attempt to:

  • check your installed PHP libraries to confirm you have all of the required libraries installed
  • run a backup
  • put your Snipe-IT into maintenance mode
  • git pull
  • clear your application caches
  • run composer install --no-dev
  • run database migrations
  • checks for OAuth keys
  • takes the database out of maintenance mode

If you're not upgrading via git, you can still use the upgrade script, but it won't be able to download the new files, and will just try to run the backups, clear caches, etc.

Upgrading Manually

Upgrading manually is unfortunately much more labor intensive (which is why we strongly recommend installing via git instead.) The most straightforward way to do this is to rename your current Snipe-IT directory (for example, to snipe-it-v3-bkup) and download the new version into a parallel directory that you name whatever your old one was named. (Keeping the same name for the new version just means you don't have to mess with the web server path settings.)

From there, copy over the old .env and your OAuth keys in storage, as well as any files or folders in your public/uploads directory and your storage/private_uploads directory.

If you wish to switch to upgrading via Git, now is a good time to do that. For instructions on how to switch from a manual install to a Git install, click here.

After Pulling the New Version Files

Whenever you pull down a new version from master or develop, or when you grab the latest official release, make sure to run the following commands via command line:

php composer.phar install --no-dev --prefer-source
php composer.phar dump-autoload
php artisan migrate
php artisan config:clear
php artisan config:cache

For windows, use:

composer install --no-dev --prefer-source
composer dump-autoload
php artisan migrate
php artisan config:clear
php artisan config:cache

(Developers should remove the --no-dev flag, so they have unit test frameworks and debugging tools.)

Forgetting to run these commands can mean your DB might end up out of sync with the new files you just pulled, or you may have some funky cached autoloader values.

It’s a good idea to get into the habit of running these every time you pull anything new down. If there are no database changes to migrate, it won't hurt anything to run migrations anyway, you’ll just see "Nothing to migrate".

If you have any issues upgrading, check the Common Issues page for a fix. If you don’t see your issue listed there, open an issue on Github and we’ll try to get you sorted out. Be sure to provide the information outlined in the Getting Help section of this site so that we have the info we need to assist you.


Did this page help you?