syncstorage-rs: Mozilla's Rust Sync Storage server

What syncstorage-rs operates

syncstorage-rs solves the server-side problem of storing and serving Mozilla Sync data. The README describes it as "Mozilla Sync Storage built with Rust," placing it within Mozilla Services infrastructure. Its intended users are engineers maintaining that synchronization service, operating the related Token server, or reproducing a deployment that follows Mozilla's service architecture. The repository does not present itself as a client library or a generic synchronization SDK.

The project is a collection of cooperating components rather than one small executable. The Cargo workspace includes `syncserver`, `tokenserver`, shared common crates, settings crates, and database-specific crates for MySQL, PostgreSQL, and Spanner. `syncserver` is listed as the default workspace member, so ordinary Cargo operations focus on that component unless another member is selected. This makes the intended service boundary visible in the repository structure.

The README links to generated service documentation under `docs/src/` and to a Swagger UI. Those are the relevant sources for endpoint routes, request formats, authentication expectations, and response behavior. The root README does not reproduce those details. Engineers should not infer compatibility with a Mozilla client from the project name alone. They should first confirm the documented API behavior and the deployment topology they intend to operate.

Cargo workspace structure and runtime dependencies

The Rust workspace is defined in `Cargo.toml`. It contains Sync server crates, Token server crates, shared abstractions, settings, and database integrations. The workspace uses edition 2024 and declares `rust-version = "1.98.1"`. That requirement should be treated as a build constraint, especially when reproducing the project with a system toolchain or a container base image whose Rust version differs from CI.

The workspace dependency list shows `actix-web` with compatibility, HTTP/2, and macro support. It also includes `diesel`, `diesel-async`, `diesel_migrations`, and `deadpool`, which point to an async database access layer with migrations and connection pooling. The presence of `Cargo.lock` means dependency resolution is represented in the repository. The root workspace explicitly sets resolver 3 because virtual workspaces do not inherit the resolver from member editions.

The repository also contains Python tooling. `pyproject.toml` requires Python 3.12 or later and lists `cryptography`, `pyfxa`, and `tokenlib` as root dependencies. Additional Python dependencies are grouped for Token server unit tests and development work. This split means the Rust build is not the only toolchain concern. Teams need to determine which Python components are required by their deployment and which are only needed for testing or local development.

Database backends and Docker build choices

The storage layer is selectable by backend. Workspace members include `syncstorage-mysql`, `syncstorage-postgres`, and `syncstorage-spanner`, and the Token server has its own MySQL and PostgreSQL crates. This separation suggests that database support is implemented through distinct crates rather than being hidden behind a single database-neutral module.

The `Dockerfile` makes the default choices explicit. It declares `SYNCSTORAGE_DATABASE_BACKEND=spanner` and `TOKENSERVER_DATABASE_BACKEND=mysql`. It accepts `MYSQLCLIENT_PKG=libmariadb-dev-compat` and installs database development packages according to the selected services. The builder also installs general build tools and Python development packages. The image therefore reflects both the Rust workspace and supporting tooling.

Changing a backend is an infrastructure decision, not merely a build-variable substitution. A deployment must account for the selected crate, client libraries, database connection configuration, migrations, and credentials. The repository layout does not confirm that MySQL, PostgreSQL, and Spanner have identical operational behavior or feature coverage. The documentation and database-specific tests should be checked before assuming that switching backends preserves all service behavior.

Local configuration and a first deployment check

The README does not give a complete installation command or a first API request. It directs users to the published service documentation and the `docs/src/` directory. The repository includes a `Dockerfile`, `Makefile`, `config/`, and `docker/`, but those files do not establish a single universal startup command in the root README.

The `Makefile` defines local development database URLs. Its defaults are `mysql://sample_user:sample_password@localhost/syncstorage_rs` for Sync Storage and `mysql://sample_user:sample_password@localhost/tokenserver_rs` for the Token server. It also defines `PATH_TO_SYNC_SPANNER_KEYS`, which points to a service-account JSON file, and references a separate `server-syncstorage` checkout for a local gRPC certificate path. These values are development inputs. They do not describe production secrets, a complete service invocation, or a schema migration procedure.

The first useful deployment check is therefore configuration discovery rather than sending a guessed request. Start with the Dockerfile arguments, inspect the settings crates and `config/` directory, and consult the generated API documentation for the expected request. The repository does not state the default port, complete environment variable set, migration invocation, or a sample response. Those values must come from the relevant project files or service documentation rather than being inferred from a generic Rust server setup.

Operational limits and failure cases

The root README is deliberately brief and delegates detailed behavior to generated documentation. It does not document authentication setup, request schemas, response semantics, database provisioning, migrations, rollback procedures, backups, health checks, or production monitoring. The presence of `CHANGELOG.md`, `tests.ini`, and CI workflow badges shows that release and test processes exist, but the root README does not explain how to use those artifacts.

The database defaults create another failure case. Sync Storage defaults to Spanner in the Dockerfile, while the Token server defaults to MySQL. A team that assumes one database serves both components may encounter missing connection settings, missing migrations, or unsupported database behavior. The repository does not document all supported combinations. This is a concrete reason to validate topology before deploying.

The required toolchain also affects upgrades. A build using an older Rust release may fail to satisfy the workspace declaration, and a Python environment below version 3.12 does not satisfy `pyproject.toml`. The repository does not say whether a container image can be rebuilt without external database services or credentials. Operators should treat those dependencies as deployment prerequisites, not assumptions.

Mozilla Sync Storage and the referenced alternative

The `Makefile` references a separate peer project named `server-syncstorage`. It uses that checkout for a local gRPC certificate path. This reference indicates that another implementation or supporting repository has been used alongside the Rust service. The root README does not document `server-syncstorage`'s API, feature set, release status, or compatibility guarantees, so the two projects should not be described as interchangeable.

The architectural difference visible in this repository is Rust workspace ownership. `syncstorage-rs` uses Actix Web and database-specific Rust crates, with separate Sync server and Token server components. The referenced project appears in a local development context rather than as a workspace member. A comparison should check authentication, endpoint behavior, schemas, deployment dependencies, and migration procedures.

For an unrelated application, a small HTTP service backed by a conventional database may be simpler. `syncstorage-rs` is more relevant when compatibility with Mozilla's synchronization model, its Token server relationship, or its established service components matters. Adoption should follow an existing Mozilla service requirement, not a general assumption that every sync application needs this workspace.

License, maintenance, and upgrade cost

The Cargo workspace declares `MPL-2.0`, while `pyproject.toml` declares `Mozilla Public License Version 2.0` for the root Python metadata. Engineers should review the license files and dependency metadata for the exact components they distribute. The README does not provide legal interpretation or a dependency license report.

The repository is not archived, and its last push was on 2026-10-16. The release list shows 0.23.3, 0.23.2, and 0.23.1 on 2026-06-18. The workspace currently declares version 0.23.3. These facts show recent repository activity and a recent listed release, but they do not establish a support window or a guarantee that every crate receives updates.

Upgrade cost includes more than changing a version number. Teams must inspect `CHANGELOG.md`, `version.json`, `Cargo.lock`, database migrations, Docker backend arguments, and Rust toolchain requirements. The repository does not document a general rollback procedure. Version-specific release notes and migration files should therefore be checked before replacing a running service.

Editorial conclusion

Adopt syncstorage-rs when operating Mozilla-compatible Sync Storage and Token server infrastructure within an existing Rust service deployment. Do not treat it as a general-purpose synchronization library without checking authentication, database, configuration, and deployment requirements. Verify the selected database backend, Rust 1.98.1 toolchain, relevant settings files, and the version-specific upgrade path first.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. mozilla-services/syncstorage-rs on GitHub
3. Project website
4. README
5. Releases