# remoteStorage.js: a browser storage library with a server sync path > remoteStorage.js keeps app data in the browser first, then syncs it to a remoteStorage server or, optionally, to Dropbox or Google Drive. The current npm tag is a 2.0.0 beta, which is the first thing to check before adopting it. **remotestorage/remotestorage.js** — ⬡ JavaScript client library for integrating remoteStorage in apps - Repository: https://github.com/remotestorage/remotestorage.js - Website: https://remotestorage.io/rs.js/docs/ - Stars: 2,424 · Forks: 143 - Language: JavaScript - License: MIT - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/remotestorage-remotestorage-js ## What remoteStorage.js actually solves Most web apps that need persistence end up with the same shape: a database behind your API, an account system you operate, and a privacy policy that explains what you do with the rows. remoteStorage.js takes a different position. The library stores user data locally in the browser and connects to remoteStorage servers, syncing data across devices and applications. The README also notes it is capable of connecting and syncing data with a person's Dropbox or Google Drive account, marked as optional. The audience is narrow and specific. You are building a client-side app, you want it to work offline, and you would rather not be the custodian of the data. The project describes itself as a grassroots effort, developed by the community, for the community, and it credits Niklas Cathor and Michiel de Jong as original authors. That framing matters: this is not a vendor product with a support contract behind it. If your app already has a server and a relational schema you are happy with, this library solves a problem you do not have. It is for apps where the user's storage account is the backend. ## Local-first storage, then a sync layer on top The architecture follows from the name. The library owns a local store in the browser and a connection to a remoteStorage server, and it reconciles the two. The repository topics list indexeddb and localstorage alongside offline-capable, offline-first, sync and synchronization, which tells you where the data lives before it ever reaches a network. A remoteStorage account is addressed by a user address, and access is granted per data module rather than per app-wide credential. The docs directory includes a page on data modules and a JavaScript API reference for the RemoteStorage class. The library is written in JavaScript and built with webpack; the package entry points at ./release/remotestorage.js for both main and browser, so the published artifact is a bundled file rather than a tree of ES modules. The sync target is not fixed to one vendor. The README points at remotestorage.io/servers for other server implementations, and names armadietto (Node.js) and mysteryshack (Rust) as recommended options for a local test server. That is the part worth internalising: the client library and the storage server are separate pieces, and you can run the server yourself. ## Installing remoteStorage.js and syncing a first key The package name on npm is remotestoragejs, not the repository name. The README's versioning section shows it used as a dependency with a caret or x range to stay within API-compatible releases. ```json "devDependencies": { "remotestoragejs": "1.x" } ``` Note the discrepancy you will hit immediately: that example pins 1.x, while the current published version in package.json is 2.0.0-beta.10. The README text has not been updated to match the beta line, so treat the snippet as a pattern for range syntax rather than a recommendation of which major to install. Before writing client code you need an account to sync against. The README recommends running a local test server, armadietto for Node.js or mysteryshack for Rust, or signing up with a hoster from the servers page. Once you have an address, the library is instantiated in the browser and given a module to work with. The API reference for the RemoteStorage class in the docs is where the exact method names live; the README does not inline them. For a visual check that data actually landed, the project points at RS Inspektor, a file browser built with this same library. For non-browser runtimes there is a dedicated page, docs/nodejs.html, linked from the README. Read it before assuming the browser build works unchanged under Node. ## The 2.0 beta is the limitation that matters most The three most recent releases are all pre-releases: v2.0.0-beta.8, v2.0.0-beta.9, and v2.0.0-beta.10. The README states the library is well-tested, actively maintained, and safe to use in production, and the last push to the repository was on 2026-08-12, so development has not stalled. But the version you get from a default install is a beta, and the README's own dependency example still shows 1.x. Those two facts sit awkwardly together. Semantic versioning, which the README says the project follows, means breaking changes land in a new major version. A 2.0.0 beta is therefore exactly the release where the API is most likely to move under you. Pin an exact version rather than a range if you build on the beta, and read the CHANGELOG before each bump. The second limitation is structural. The library depends on a remoteStorage-compatible server existing and being reachable for sync to mean anything. If you cannot run armadietto or mysteryshack, or your users will not sign up with a hoster, you are left with a local browser store and no cross-device story. The optional Dropbox and Google Drive connections soften that, but they are described as optional, not as the primary path. Finally, the README does not document rollback or migration behaviour for the local store. If you ship a schema change and need to move users back, the README is silent on how. ## How this differs from Firebase and Supabase The obvious alternative for a browser app that needs sync is a backend-as-a-service such as Firebase or Supabase. The difference is not feature count, it is who holds the data and where the source of truth sits. With Firebase or Supabase, the database is the source of truth and the client is a view onto it. Auth, storage and sync are one managed product, which removes operational work but puts the user's data in your project's account. remoteStorage.js inverts that: the browser holds the data, the user's remoteStorage account holds the synced copy, and your app never sees a central table. You take on the job of running or choosing a server, and in exchange you do not become the data controller. A second alternative sits closer to home: a plain browser store such as IndexedDB or localStorage with your own sync code. That is genuinely less machinery, and for a single-device app it is the right call. What you give up is per-module access control and the cross-device reconciliation the library already implements. The repository topics list both indexeddb and localstorage, so the library is not replacing those APIs so much as layering an account and a sync protocol over them. ## Licence, maintenance and upgrade cost The licence is MIT, declared in package.json and shipped as a LICENSE file at the repository root. MIT is permissive: you can use the library in closed-source products, and the main obligation is retaining the copyright and permission notice. That is the general shape of the licence, not legal advice for your situation; if you redistribute a modified bundle, read the LICENSE file itself. On maintenance, the last push was on 2026-08-12, and the most recent release tag, v2.0.0-beta.10, is dated 2026-08-14. The project is not archived. The README says new issues usually receive a response within 24-48 hours, which is a claim about the issue tracker rather than a commitment about releases. The upgrade cost is concentrated in the 1.x to 2.x transition. The release process runs the test suite, lint, a TypeScript declaration build and a production webpack build before publishing, and the package ships generated type declarations under release/types. Those declarations are useful, but they also mean a major bump changes your compile surface, not just runtime behaviour. ## Conclusion Build on remoteStorage.js if you want per-user data ownership and an offline-first client without running your own backend. Skip it if you need a stable 2.x release today or a managed sync service. Before committing, check the npm dist-tag for remotestoragejs to see whether 2.0.0 is still beta, and read docs/nodejs.html if your code runs outside a browser. ## FAQ ### What is remoteStorage.js? It is a JavaScript client library for integrating remoteStorage into apps. It stores user data locally in the browser and connects to remoteStorage servers to sync data across devices and applications, with optional Dropbox or Google Drive sync. ### What is the npm package name for remoteStorage.js? The package is published as remotestoragejs, and package.json points main and browser at ./release/remotestorage.js. The current version listed in package.json is 2.0.0-beta.10. ### Does remoteStorage.js work with localStorage and IndexedDB? The repository topics list indexeddb and localstorage alongside offline-capable and offline-first, so the library builds on browser storage rather than replacing it. The README does not spell out which store is used in which situation. ### How do I run a server to test remoteStorage.js against? The README recommends armadietto for Node.js or mysteryshack for Rust as local test servers, or getting an account with a hoster. Other implementations are listed on the remoteStorage servers page. ### Can I use remoteStorage.js outside the browser, for example with Node.js? The README links a dedicated page at docs/nodejs.html for usage with Node.js. It does not describe the Node path in the README body itself, so read that page before assuming the browser build applies unchanged. ### Is remoteStorage.js safe to use in production? The README states it is well-tested, actively maintained and safe to use in production. The three most recent releases are all 2.0.0 pre-releases, so verify which version you are pinning before you rely on that statement. ## Sources - [License: MIT](https://github.com/remotestorage/remotestorage.js/blob/master/LICENSE) - [Project website](https://remotestorage.io/rs.js/docs/) - [README](https://github.com/remotestorage/remotestorage.js/blob/master/README.md) - [Releases](https://github.com/remotestorage/remotestorage.js/releases) - [remotestorage/remotestorage.js on GitHub](https://github.com/remotestorage/remotestorage.js) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/remotestorage-remotestorage-js