# Snipe-IT: self-hosted IT asset and license tracking for teams that outgrew a spreadsheet

> Snipe-IT is an AGPL-3.0 Laravel application for tracking who holds which laptop, what it cost, and which software licenses are in use. It is a web app you host yourself, and the Docker Compose file in the repository is the shortest path to a running instance.

**grokability/snipe-it** — A free open source IT asset/license management system

- Repository: https://github.com/grokability/snipe-it
- Website: https://snipeitapp.com
- Stars: 14,985 · Forks: 4,002
- Language: PHP
- License: AGPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/grokability-snipe-it

## What Snipe-IT actually records, and who ends up using it

The README frames the project narrowly: "Knowing who has which laptop, when it was purchased in order to depreciate it correctly, handling software licenses." That is the whole scope. Snipe-IT is a system of record for assets and licenses, not a monitoring tool and not a discovery scanner. Nothing in the repository suggests it reaches out to endpoints and inventories them on its own.

The audience follows from that scope. An IT operations team that already knows what it owns, but tracks it in a spreadsheet that three people edit, is the target user. So is an organization that needs depreciation dates and license seat counts in one place, because those two questions usually arrive together during budget season. The project is built on Laravel 12 and ships as web-based software, so there is no executable to hand around; the README says it plainly: "This is web-based software. This means there is no executable file (aka no .exe files), and it must be run on a web server and accessed through a web browser."

That constraint shapes everything else. Someone has to run the server. A single IT administrator can do it, but the tool is not something a non-technical staff member installs on a laptop.

## How the pieces fit: Laravel app, MariaDB, and a storage volume

The repository layout tells you most of the architecture. There is an app/ directory, a config/ directory, database/ migrations, an artisan entry point, and a composer.json for PHP dependencies. The front end is compiled with Laravel Mix: package.json defines development and production scripts that call mix, and pulls in AdminLTE, Bootstrap 3, jQuery, Chart.js and FullCalendar. That is a conventional server-rendered Laravel application with a bundled admin theme, not a separate API-first backend with a JavaScript client.

The production Compose file makes the runtime shape explicit. Two services: app, built from the snipe/snipe-it image, and db, running mariadb:11.4.7. The app service mounts a named volume at /var/lib/snipeit and maps ${APP_PORT:-8000} to port 80 inside the container. The database service gets its credentials from environment variables (MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD, MYSQL_ROOT_PASSWORD) and defines a healthcheck using healthcheck.sh with --connect and --innodb_initialized. The app service waits on that healthcheck through depends_on with condition: service_healthy.

Configuration flows through a .env file. The example file in the repository marks APP_ENV, APP_KEY, APP_URL, the database block and the filesystem disks as required sections. Two details in that file are worth noting because they bite people later. First, APP_KEY is set to ChangeMe in the example, which is a placeholder rather than a usable value. Second, the database section recommends DB_CONNECTION=mariadb when the server is MariaDB, with the comment that this makes the backup and restore tooling invoke mariadb / mariadb-dump instead of the deprecated mysql / mysqldump symlinks. If you run MariaDB and leave the connection set to mysql, the backup tooling takes the older path.

File storage is split between PRIVATE_FILESYSTEM_DISK and PUBLIC_FILESYSTEM_DISK, defaulting to local and local_public, with commented-out s3_private and s3_public alternatives. Uploaded files therefore live on the app container's filesystem by default, which is why the Compose file mounts a volume at /var/lib/snipeit.

## Installing Snipe-IT with Docker Compose

The README points to the readme.io installation manual for server installs and mentions a Docker image for people who prefer containers. The repository ships the Compose file that image is meant to run under, and that is the shortest documented path.

Start by creating your environment file from the example. The Compose file reads it through env_file, and the database service pulls DB_DATABASE, DB_USERNAME, DB_PASSWORD and MYSQL_ROOT_PASSWORD from the same source.

```bash
cp .env.example .env
```

Open .env and fill in the required sections. At minimum you need a real APP_KEY, a reachable APP_URL, and the database block. If your database is MariaDB, the example file tells you to set the connection accordingly.

```bash
APP_ENV=production
APP_DEBUG=false
APP_KEY=ChangeMe
APP_URL=null
DB_CONNECTION=mariadb
DB_DATABASE=snipeit
DB_USERNAME=snipeit
DB_PASSWORD=changeme
MYSQL_ROOT_PASSWORD=changeme_root
```

Then bring the stack up. The app service publishes port 8000 by default, and the database healthcheck gates the app's start.

```bash
docker compose up -d
```

Once the containers are healthy, browse to the host on port 8000 and you should land on the Snipe-IT setup screen, where the application finishes its own configuration against the database you supplied. From there the first real task is creating an asset model, then an asset, then checking it out to a user, which is the loop the whole application is built around.

If you would rather not use Docker, the README directs you to the installation manual at snipe-it.readme.io, and the repository also contains an install.sh script, a Vagrantfile, an ansible/ directory and several Dockerfile variants (Dockerfile, Dockerfile.alpine, Dockerfile.fpm-alpine) for people building their own images. The README does not document rollback or downgrade steps; it points to the upgrading documentation instead.

## Where Snipe-IT stops being the right tool

The clearest limitation is that Snipe-IT does not discover anything. If nobody enters an asset, the asset does not exist in the system. The README's related-projects list is the honest signal here: jamf2snipe, Kandji2Snipe, MosyleSnipeSync, UniFi to Snipe-IT and Rudder2Snipe all exist to push data from other systems into Snipe-IT. Those integrations are third-party, and the README is explicit that "Snipe-IT cannot provide support for these projects" and makes "no guarantees as to the reliability, accuracy or maintainability of these libraries." So the sync layer is your problem, not the project's.

Second, the deployment surface is not small. Ubuntu base image, Apache, PHP 8.3 with a long list of extensions (ldap, mysql, gd, xml, mbstring, zip, bcmath, redis), MariaDB, and a persistent volume. The Dockerfile shows all of it. That is a normal LAMP-shaped footprint, but it means upgrades touch a PHP runtime and a database, not just an application binary.

Third, the front end is built on Bootstrap 3 and AdminLTE 2, which package.json pins at ^3.4.1 and ^2.4.18 respectively. Those are old major versions. It does not affect whether the asset records are correct, but it does mean the interface carries the conventions of an earlier web era, and anyone expecting a modern single-page app will be surprised.

Finally, the README is a pointer document. Installation, upgrading, translations and the user manual all live on readme.io. If you want to evaluate the project by reading the repository alone, you will not find the operational detail you need there.

## Snipe-IT compared with a network discovery tool

The most useful comparison is with discovery-first inventory tools such as GLPI or Lansweeper, which scan the network and build an inventory from what they find. The difference in approach is the direction of the data. A discovery tool starts from observed devices and asks you to reconcile the results. Snipe-IT starts from records you create and asks you to keep them accurate, with integrations feeding it from systems that already know about the hardware.

That makes Snipe-IT better at the questions a discovery scan answers poorly: who signed for this laptop, what did it cost, when does it depreciate, how many seats of a license are consumed. It makes Snipe-IT worse at the question a scan answers instantly: what is currently plugged into the network. If your problem is that you genuinely do not know what you own, a discovery tool is the right first step and Snipe-IT is the wrong one. If you know what you own and cannot answer who has it, the ordering reverses.

The two are not mutually exclusive. The jamf2snipe and Kandji2Snipe scripts in the README's list exist precisely because teams run a management platform and want Snipe-IT as the reporting layer. Just budget for maintaining that bridge yourself, since the README disclaims support for it.

## Licence, upgrades and the maintenance bill

Snipe-IT is licensed AGPL-3.0. That is a copyleft licence with a network clause: if you modify the software and let users interact with it over a network, the AGPL's source-availability obligation can reach your modified version. For most internal deployments where you run the software unmodified, this is a non-issue. It becomes a real consideration if you fork the code, customize it heavily, or embed it in something you offer to others. This is a description of the licence's shape, not legal advice; if your use is unusual, get a lawyer to read it.

The repository is not archived, and the last push was on 2026-09-21. Releases have been frequent: v8.7.0 on 2026-08-11, v8.7.1 on 2026-08-17, v8.7.2 on 2026-08-19. The README says the project is actively developed and releases frequently, and the release dates in the repository are consistent with that.

The upgrade cost is the part people underestimate. The README sends you to the upgrading documentation rather than describing the process inline, and there is an .upgrade_requirements.json file at the repository root, which suggests version-specific requirements are tracked as part of the upgrade path. The practical implication: treat upgrades as a maintenance task with its own checklist, not a pull of a new image. The Compose file's APP_VERSION variable defaults to latest, which is convenient for a first install and a poor default for a production instance you cannot afford to have change underneath you. Pin a version.

## Conclusion

Adopt Snipe-IT if you need a self-hosted record of hardware assignments, purchase dates and license seats, and you have someone who can run a PHP application and its database. Do not adopt it if you want a hosted service with no server of your own, or if your real need is network discovery rather than a system of record. Before committing, verify your PHP and database versions against the requirements page, confirm that the AGPL-3.0 obligations fit how you intend to distribute any modified version, and read the upgrading documentation so you know what a version jump involves.

## FAQ

### What does Snipe-IT do?

It is a free open source IT asset and license management system. The README describes it as a project for asset management in IT operations, covering who has which laptop, when it was purchased for depreciation, and software licenses.

### How much does Snipe-IT cost?

The project is described as FOSS and the repository is licensed AGPL-3.0, so there is no licence fee. Your costs are the server and database you run it on, plus the staff time to maintain them.

### Can I host Snipe-IT myself?

Yes, self-hosting is the only option. The README states that it is web-based software with no executable file, and that it must be run on a web server and accessed through a browser. It runs on macOS, Linux and Windows, and a Docker image is available.

### How do I install Snipe-IT?

The README points to the installation manual at snipe-it.readme.io for server installs. The repository also ships a docker-compose.yml with an app service and a mariadb:11.4.7 database service, which is the container path.

### How do I install Snipe-IT on Docker?

Copy .env.example to .env, fill in the required app and database settings, then run docker compose up -d. The app service publishes port 8000 by default and waits for the database healthcheck before starting.

### How do I use the Snipe-IT API?

The README refers to a JSON REST API and lists third-party libraries for it, including SnipeSharp for .NET, SnipeitPS for PowerShell and WWW::SnipeIT for Perl. It notes that those libraries were created by third parties and that Snipe-IT cannot provide support for them.

## Sources

- [grokability/snipe-it on GitHub](https://github.com/grokability/snipe-it)
- [License: AGPL-3.0](https://github.com/grokability/snipe-it/blob/master/LICENSE)
- [Project website](https://snipeitapp.com)
- [README](https://github.com/grokability/snipe-it/blob/master/README.md)
- [Releases](https://github.com/grokability/snipe-it/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/grokability-snipe-it