Servas: a Laravel and Svelte bookmark manager you host yourself

The problem Servas targets: bookmarks that live in someone else's account

Browser sync keeps bookmarks tied to a vendor account. Servas takes the opposite position. The README describes it as a self-hosted bookmark management tool based on Laravel and Inertia.js, with Tailwind CSS and Svelte on the frontend. The data sits in a database you control, whether that is SQLite, MySQL or MariaDB, and the app is reached through a browser at your own URL.

The intended user is someone who already has a place to run a container or a PHP application. The Docker path is described as the preferred way to use Servas with SQLite, which avoids a second database container entirely. The manual path assumes PHP 8.4, Composer, Node.js and Git, which points at a developer or a sysadmin rather than a general audience.

The feature list is deliberately conventional: tags, groups that can be nested, smart groups built from tag membership, multiple user accounts, import and export in JSON and HTML, a dark and light theme, and two factor authentication. None of that is novel. The value is in where the records end up, not in what the interface does.

How the Laravel, Inertia.js and Svelte stack shapes the app

Servas is a server-rendered Laravel application with an Inertia.js bridge to Svelte components and Tailwind CSS for styling. That combination matters for how you operate it. Routing, authentication, sessions, migrations and the database layer come from Laravel. The page components are Svelte files delivered through Inertia rather than as a separate API consumed by a standalone frontend.

The practical consequence is that the deployable unit is a PHP application plus a set of compiled frontend assets. In the Docker image those assets are already built. In the manual path you run npm install and npm run build before the app is usable, which is why Node.js appears in the requirements list next to PHP.

Data flow follows the same shape. A request hits Laravel, the controller loads bookmarks, tags or groups from the configured database, and Inertia passes that data into the Svelte page component. There is no documented public API in the supplied material, so anything that needs to read or write bookmarks programmatically would have to go through the database or the import and export files. The repository topics list inertiajs, laravel, php, sveltejs and tailwindcss, which matches this architecture.

The organisational model is the part worth understanding before you migrate. Tags and groups are separate concepts. Groups can be nested, so they behave like folders. Smart groups are not folders at all: the README states they group bookmarks based on their belonging tags. That means a smart group is a saved query over tag membership, and its contents change as you retag bookmarks. If you expect a smart group to hold a fixed list, it will not.

Installing Servas with Docker: the key generation step people miss

The Docker route uses the official image beromir/servas. You create a .env file in the same directory as compose.yaml, copy the contents of the example env file into it, change APP_URL, and set a strong DB_PASSWORD if you are running MariaDB. The README notes that the password is only required when Servas is used with MariaDB, which follows from SQLite being the default recommendation.

Start the containers:

docker compose up -d

Then generate the application key inside the running container:

docker exec -it servas php artisan key:generate --force

Restart the containers with docker compose restart, then open the register route at your instance URL and create a user account. Skipping the key generation step is the most likely first-run failure, because the command runs against the already-started container rather than during image build. The example files are split by database: docker/compose.prod.yaml with docker/.env.prod.example for SQLite, and docker/mariadb-example/compose.prod.yaml with its own env example for MariaDB. MySQL is also listed as supported.

Two configuration keys are documented for the .env file. SERVAS_ENABLE_REGISTRATION takes true or false and controls whether new users can sign up. SERVAS_SHOW_APP_VERSION takes true or false and controls whether the version number appears in the profile dropdown. The README adds that after changing .env you must restart the application container, so these are read at boot rather than per request.

The manual install path and what PHP 8.4 costs you

The manual install is documented as a sequence: clone the repository, then run composer install --optimize-autoloader --no-dev, then npm install, then npm run build. You create .env from .env.example, and if you use SQLite you must remove the MySQL section from that file and uncomment the SQLite section. Then php artisan migrate and php artisan key:generate.

The PHP 8.4 requirement is the constraint that will decide this path for many people. Distributions that ship an older PHP by default will need an additional repository or a container to satisfy it, and that work sits outside anything Servas documents. The same applies to the Node.js requirement: it is only needed to produce the built assets, so a build-once, deploy-many setup is possible, but the README does not describe one.

Because there is no documented upgrade command in the supplied material, the migration step is the piece to plan around. Any release that changes the schema will need php artisan migrate run against the existing database, and the README does not describe a rollback procedure. Take a database dump before upgrading. With SQLite that is a file copy, which is one more argument for the SQLite variant on a small instance.

Where Servas is thin: collaboration, API access and version drift

Multiple user accounts are supported, but the README does not describe sharing, permissions or a shared bookmark space. Each account appears to hold its own bookmarks, tags and groups, and the only documented account-level control is SERVAS_ENABLE_REGISTRATION. If your requirement is a team library where several people curate one collection, the supplied material does not show how Servas would do that.

The second gap is programmatic access. There is no API documented in the README. Import and export in JSON and HTML are the only described ways to move data in bulk, and the browser extensions are a separate repository at github.com/beromir/servas-extension. If you want to script bookmark ingestion from another tool, you would be writing against an interface the project does not document.

The third is release cadence. The listed releases are v1.0.0 in July 2025, v1.1.0 in November 2025 and v1.1.1 in April 2026. That is three releases across roughly nine months, with a five-month gap between v1.1.0 and v1.1.1. Nothing here says the project is abandoned, and the repository is not archived, but a self-hoster should read the release notes for each jump rather than assume patch-level changes. Small version numbers do not guarantee small schema changes.

Alternatives: linkding and the single-user SQLite model

The closest comparison in the self-hosted bookmark space is linkding, which is commonly deployed as a single Python application with SQLite and a Docker image. The difference in approach is not cosmetic. Servas is a Laravel application with a compiled Svelte frontend, so operating it means PHP 8.4, a Composer dependency tree, a Node build step in the manual path, and database migrations run through php artisan. linkding's stack is smaller, which generally means fewer moving parts to upgrade.

What Servas offers in exchange is the grouping model. Nested groups plus smart groups derived from tags is a more structured way to organise a large collection than a flat tag list, and the README treats both as first-class features. If your bookmarks are already organised hierarchically in a browser, that structure has somewhere to go.

A second comparison point is browser sync itself. It costs nothing to operate and requires no server. Servas only makes sense if you specifically want the records outside the vendor account, or want a single collection that survives switching browsers. That is a real reason, but it is the reason, not a side benefit. If it does not apply to you, the operational cost of Servas is not justified.

Licence, maintenance and what to check on your instance

Servas is licensed under GPL-3.0. For self-hosting that has little practical effect: you can run it, modify it and redistribute it under the same terms. If you plan to embed Servas in a product or offer it as a hosted service, the copyleft terms apply to derivative distribution, and that is a question for a lawyer rather than for this article. The licence identifier is stated in the repository metadata.

Maintenance cost is dominated by the runtime rather than the application. The Docker image bundles PHP and the built assets, so routine upgrades are a pull and a restart. The manual path means tracking PHP 8.4, Composer packages and the Node build toolchain separately. The project documents two .env keys and no upgrade procedure, so the release notes are the only upgrade guidance available.

Three checks are worth running before you move real bookmarks across. Create your accounts and then set SERVAS_ENABLE_REGISTRATION=false, restarting the container as the README requires, and confirm the register route is closed. Confirm your PHP version satisfies 8.4 if you are not using Docker. And run a JSON or HTML export from your existing browser and import it, because import and export are the only documented migration path and a partial import is easier to discover on a test instance than after you have deleted the originals.

Editorial conclusion

Adopt Servas if you already run a small server or NAS, you want bookmark data in your own database, and you are comfortable with the PHP 8.4 requirement and the two-step Docker setup where you generate the application key after the first start. Do not adopt it if you need shared or collaborative bookmarking, or if you want to avoid running a web application at all. Before committing, verify three things on your own instance: that registration is closed once your accounts exist, that your PHP version satisfies the 8.4 requirement in the manual install path, and that a JSON or HTML export round-trips your existing bookmark file.

Official sources

1. beromir/Servas on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases