I Built an Open-Source Alternative to Browser Sync — Your Data, Your Server

ALIBI Ghazi — Sat, 24 Oct 2026 14:27:25 +0000

I wanted to sync my bookmarks, browsing history, and open tabs across devices without depending on Google or another third-party sync service.

So I built HelixSync — an open-source, self-hosted solution that puts you in control of your browser data.

What is HelixSync?

HelixSync lets you sync your browsing experience across your devices using a server that you host yourself.

It works with Helium and Chromium-based browsers, including Chrome, Brave, Edge, and Vivaldi.

Here's what you can sync:

🔖 Bookmarks — Keep your bookmarks, folders, and changes in sync.
🕘 Browsing history — Access synced history across connected browsers.
📑 Open tabs and windows — Pick up where you left off on another device.
🎨 Tab groups — Sync group names, colors, and collapsed states.

Whether you're switching between computers or just want the same browsing setup everywhere, HelixSync helps keep everything in sync.

Your data stays yours

I wanted a solution where I could control where my browsing data is stored instead of handing it over to a third-party service.

HelixSync uses end-to-end encryption. Your synced browsing data is encrypted so the server stores ciphertext rather than readable bookmarks and history.

No Google account. No Microsoft account. No third-party sync service required.

You can also manage your connected devices through a web dashboard and revoke access whenever you want.

What about passwords?

HelixSync intentionally does not sync passwords. It focuses on browser data such as bookmarks, history, tabs, and tab groups.

For password management, I recommend Vaultwarden, a lightweight server compatible with Bitwarden clients that you can host yourself.

I prefer keeping these responsibilities separate: HelixSync handles browser synchronization, while Vaultwarden handles passwords.

Together, they can help you build a self-hosted setup without relying on a third-party cloud service for either purpose.

Easy to get started

You don't need a complicated infrastructure to run HelixSync.

With Docker Compose, you can get the server, database, and web dashboard running on your own machine or server.

The basic setup is straightforward:

Deploy HelixSync on your server.
Create your account and save your recovery code.
Install the browser extension.
Connect your browsers to your server.
Choose which data you want to sync.

Once everything is connected, synchronization happens in the background.

You can also run it behind your own domain with HTTPS and manage your connected devices through the dashboard.

Built for people who value privacy and self-hosting

HelixSync is open source and released under the MIT license.

The goal is simple: give people a way to sync their browser data without having to depend on someone else's infrastructure.

If you already run a home server, a VPS, or a collection of self-hosted applications, HelixSync might fit right into your setup.

Try HelixSync

🚀 GitHub: https://github.com/GhaziAlibi/helixsync

🌐 Chrome Web Store: https://chromewebstore.google.com/detail/helixsync/pkklkldoippchkhpokglpolepbcbjdfk

I'd love to hear your feedback, ideas, and suggestions. Contributions and bug reports are welcome!

A question for the community: Do you prefer using browser-provided sync services, or would you rather host your own? What features would you want from a self-hosted browser sync solution?

Why I Built an Interactive Sandbox to learn Distributed Systems

ALIBI Ghazi — Wed, 14 Oct 2026 22:15:42 +0000

When you first start studying system design and distributed systems, almost everything is taught through static boxes and arrows.

Someone draws a Load Balancer, an App Server, a Redis Cache, and a Database, and says: "Put a cache in front of the database to handle read traffic, and add retries for fault tolerance."

On paper, it makes total sense. In practice, systems behave in weird, non-linear ways under load:

What happens when your 92% cache hit rate drops for 30 seconds?
What happens when a caller times out and retries, while the downstream service keeps processing the abandoned request anyway?
How quickly do queues explode once traffic crosses steady-state capacity?

As I started diving deeper into caching, replication, message queues, and fault tolerance, I realized I couldn't really internalize these concepts just by reading about them. I needed to experiment with them.

That's why I started building ShardCraft.

Turning Theory into Interactive Labs

My goal with ShardCraft is to take complex engineering concepts and turn them into interactive simulations where you can actually see how systems behave under load, failure, and growth.

Even building the simplified mathematical models for the site has taught me a ton—having to think through Poisson request arrivals, exponential service-time tails, retry backoff/jitter, and the difference between async slot-freeing vs. thread-per-request blocking.

Learning in Public (Mistakes Included)

I'm definitely not claiming to be a distributed systems expert. I'm building this to learn, ask questions, test my assumptions, and share what I discover along the way.

Through this series and on the site, I'll be sharing:

Deep-dive explanations into how real systems scale and fail
Interactive labs where you can break architectures in your browser
Corrections & iterations—the things I modeled wrong at first before figuring them out

Come Break Some Systems With Me

Whether you're just starting out with system design or you've been firefighting production incidents for years, I'd love to learn with you (and from you!).

👉 Explore the guides and interactive labs here: shardcraft.dev

If you take a look at the simulation notes or labs, let me know what you think—or drop a comment below on what distributed systems topic you'd love to see simulated next!

DEV Community: ALIBI Ghazi