HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
FrigadeHQ
remote-storage
TypeScript2024–2024
FrigadeHQ / remote-storage

remote-storage

remoteStorage is a simple library that combines the localStorage API with a remote server to persist data across sessions, devices, and browsers. It works as a simple key value database store and backend with support for React, Next.js, Vue, Node, or any Javascript stack

3Distinct people
5Mentions
0Explicit recommenders
1.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

remoteStorage is a simple library that combines the localStorage API with a remote server to persist data across sessions, devices, and browsers. It works as a simple key value database store and backend with support for React, Next.js, Vue, Node, or any Javascript stack

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by day5 dated mentions

Observed mentions: 2024-01-09 17:28:47 UTC to 2024-01-24 01:56:41 UTC.

0122024-01-09 00:00:00 UTC to 2024-01-10 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsJan 92024-01-10 00:00:00 UTC to 2024-01-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-11 00:00:00 UTC to 2024-01-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-12 00:00:00 UTC to 2024-01-13 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2024-01-13 00:00:00 UTC to 2024-01-14 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-14 00:00:00 UTC to 2024-01-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-15 00:00:00 UTC to 2024-01-16 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-16 00:00:00 UTC to 2024-01-17 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsJan 162024-01-17 00:00:00 UTC to 2024-01-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-18 00:00:00 UTC to 2024-01-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-19 00:00:00 UTC to 2024-01-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-20 00:00:00 UTC to 2024-01-21 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-21 00:00:00 UTC to 2024-01-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-22 00:00:00 UTC to 2024-01-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-23 00:00:00 UTC to 2024-01-24 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-24 00:00:00 UTC to 2024-01-25 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJan 24

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jan 92024-01-09 00:00:00 UTC2024-01-10 00:00:00 UTC110
Jan 102024-01-10 00:00:00 UTC2024-01-11 00:00:00 UTC000
Jan 112024-01-11 00:00:00 UTC2024-01-12 00:00:00 UTC000
Jan 122024-01-12 00:00:00 UTC2024-01-13 00:00:00 UTC211
Jan 132024-01-13 00:00:00 UTC2024-01-14 00:00:00 UTC101
Jan 142024-01-14 00:00:00 UTC2024-01-15 00:00:00 UTC000
Jan 152024-01-15 00:00:00 UTC2024-01-16 00:00:00 UTC000
Jan 162024-01-16 00:00:00 UTC2024-01-17 00:00:00 UTC000
Jan 172024-01-17 00:00:00 UTC2024-01-18 00:00:00 UTC000
Jan 182024-01-18 00:00:00 UTC2024-01-19 00:00:00 UTC000
Jan 192024-01-19 00:00:00 UTC2024-01-20 00:00:00 UTC000
Jan 202024-01-20 00:00:00 UTC2024-01-21 00:00:00 UTC000
Jan 212024-01-21 00:00:00 UTC2024-01-22 00:00:00 UTC000
Jan 222024-01-22 00:00:00 UTC2024-01-23 00:00:00 UTC000
Jan 232024-01-23 00:00:00 UTC2024-01-24 00:00:00 UTC000
Jan 242024-01-24 00:00:00 UTC2024-01-25 00:00:00 UTC101

What Hacker News says

5 sources

Show HN: RemoteStorage – sync localStorage across devices and browsers

Hey HN! Wanted to share a new library and server I've recently been working on called remoteStorage. When building frontends with Javascript, the native localStorage API is super useful for keeping track of state between sessions in the same browser, but it's not as good a solution when your data needs to be shared across multiple devices or browsers. For instance, let's say you want to show a welcome modal to all new users that sign up for your product. If you use localStorage to track if a user has already seen this modal, your users will end up getting the experience repeatedly every time they switch devices or browsers, or whenever Chrome decides to nuke your data. I built remoteStorage to help fix that. Using the same API as localStorage, remoteStorage allows you to easily read and write data on the fly while maintaining state across
Read the rest
browsers and devices in order to provide a better user experience. The project is built as a monorepo in Typescript and contains a JS library that works across any Javascript stack (including Node.js and React Native) and is lightweight (~1 kb minified). The server is built with Nest.js with a disk-persisted Redis Database. It can be deployed in a few minutes using Docker. One of the biggest challenges when building this was coming up with a secure scheme for handling authentication while still keeping the API dead simple for frontend devs to use. While the project is intended to store non-sensitive data like impression events/preferences, I still wanted to make sure data couldn’t easily leak or be tampered with. One solution has been to generate a unique secret UUID per user on your own backend to identify the user. Alternatively, you could create a simple wrapper/proxy API around remoteStorage that uses your own authentication method to verify the user's identity before allowing them to access the data (this is super simple to build with React Server Components). Then, you could pick a secure and secret Instance ID that is not publicly available to ensure that only your application can access the data. Has anyone felt the same pain points with localStorage before? Is this solution useful? Let me know what you think or ideas for how I can improve it :)
129 points · Open discussion

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.