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.
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.
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:
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
- clear your application caches
composer install --no-dev
- run database migrations
- checks for OAuth keys
- checks your directory permissions
- 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 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
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.
Whenever you pull down a new version from
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.
Updated over 1 year ago