I found myself asking an odd question: did even a self-hosted vault need to be online at all, for something this sensitive? My server was mine, encrypted, and reasonably secure — but it was still a service running somewhere, reachable over a network, with all the small risks that implies. For my most critical handful of accounts, I wanted something that couldn't be touched over a network at all, because it simply wasn't on one.

Looking for "Offline" as a Feature, Not a Limitation

Most password managers treat "offline" as something to work around — a fallback mode for when you lose connectivity, not a design choice. I wanted the opposite: a tool built from the ground up to never need a network connection in the first place.

That search led me to KeePassXC, an open-source password manager with a completely different model than most. There's no server. No account to create. No sync service baked in. Your entire vault is a single encrypted file, sitting wherever you put it, and the only way in is your master password (optionally combined with a key file or hardware security key).

Setting It Up

Installing KeePassXC felt almost anticlimactic after wrestling with servers and certificates for other tools. Download it, open it, create a new database, set a strong master password. That's it. No account creation screen. No email verification. No terms of service to scroll past. The vault file it created lived exactly where I told it to — a local folder, nothing more.

I moved my most sensitive credentials into it: my primary email, my domain registrar, my banking logins, the handful of accounts where "if this is compromised, everything else falls too" applies. Each entry encrypted inside a single .kdbx file that means nothing to anyone without my master password.

The Auto-fill Surprise

I'd assumed "offline password manager" meant "manually copy-pasting passwords forever," and I was ready to accept that trade-off for my most sensitive accounts. I was wrong. KeePassXC has a browser integration that handles auto-fill just like any cloud-based manager — the browser extension talks to the locally running KeePassXC app, which unlocks the relevant entry only when I approve it. The convenience I expected to lose, I mostly kept.

The Part That Actually Changed My Thinking

A few weeks in, I needed to log into that primary email account from a different laptop while traveling. My cloud-synced vault would have handled that instantly. KeePassXC didn't, because the vault file simply wasn't on that machine — and for a second, that felt like a limitation.

Then I realized: that's exactly what I'd wanted. The accounts I'd put in KeePassXC were the ones I deliberately didn't want accessible from just any device, anywhere, the moment I typed a master password. I ended up copying the file over manually via a USB drive, and for these specific accounts, that small bit of friction felt like a feature rather than an inconvenience.

For everyday, lower-stakes accounts, I still use my synced vault. For the handful of accounts that really matter, KeePassXC's offline-by-default approach has become the deliberate extra step between "convenient" and "compromised."

What My Setup Actually Looks Like Now

• A self-hosted, synced vault for daily accounts — subscriptions, shopping sites, general logins
• A completely offline KeePassXC vault for the handful of accounts that could unravel everything else if breached
• Browser auto-fill still works for both, just through different mechanisms
• The offline vault gets backed up manually, on my terms, to storage I control directly — no automatic cloud sync at all

The Bigger Lesson

Not every account needs the same level of protection, and not every password manager needs to optimize purely for convenience. Some accounts are worth the extra ten seconds of friction in exchange for a vault that, by design, was never reachable over a network to begin with.

KeePassXC didn't replace my everyday password manager. It gave me a second, deliberately harder-to-reach option for the accounts where "harder to reach" is exactly the point.

This is part of my "Everyday Open Source" series, where I highlight open-source tools that quietly make daily life better.

Try It Yourself

• Website: keepassxc.org
• GitHub (source code): github.com/keepassxreboot/keepassxc
• Documentation: keepassxc.org/docs

I sat there for a second, genuinely annoyed. I wasn't trying to stream a movie or download anything questionable — I was grabbing an official, legal open-source operating system image, and I still had to sit through ads bolted onto a client I'd never actually chosen, just inherited from some "recommended download" years ago.

That was the moment I actually looked at what else was out there.

What I Didn't Know I'd Accepted

Torrenting, at its core, is just a protocol — a decentralized way to distribute files by sharing pieces of them across many people at once, instead of everyone hammering a single server. It's how a lot of legitimate large files move: Linux distributions, open-source software releases, public domain media, game patches from certain platforms, scientific datasets shared by research institutions.

The protocol itself is neutral. The client I'd been using for it, though, wasn't neutral at all — it was bundled with ads, occasionally prompted me to install "recommended" browser extensions I never wanted, and generally felt like software that existed to monetize me, not to serve me.

I'd just never questioned it, because it worked well enough and I wasn't paying anything for it directly. Except I was — in attention, in bundled junk, in trust handed over without much thought.

Enter qBittorrent

qBittorrent is a free, open-source torrent client built specifically as a clean alternative to the ad-heavy, bundleware-laden clients that dominate search results. No ads. No bundled toolbars. No sketchy "recommended downloads" during install. Just the actual torrenting functionality, built by a community instead of a company trying to monetize the interface.

I installed it expecting to have to hunt for a "decline all the extra offers" checkbox somewhere in the setup, the way I'd had to with nearly every free download tool I'd used before. There wasn't one. The installer was just... the installer. Refreshing, honestly, in how little there was to be suspicious of.

Using It

The interface felt immediately familiar — anyone who's used a torrent client before will recognize the layout instantly: a list of active downloads, transfer speeds, seeding ratios, all clearly laid out without a single banner competing for space.

I went back to that Linux ISO download. Same file, same protocol, same network of peers sharing pieces of it — except this time, nothing loaded except the actual download. It finished in about the same time. The difference wasn't speed. It was everything surrounding the download that simply wasn't there anymore.

What Actually Changed

• No ads, no bundled software, no dark-pattern install prompts
• Built-in search functionality for finding legitimate torrents (Linux distros, open-source releases, public domain content) without needing sketchy third-party sites
• Bandwidth scheduling, so downloads don't hog my connection during work hours
• Cross-platform — Windows, Mac, and Linux, all with the same clean interface
• Regularly updated by an active open-source community, rather than a company trying to squeeze more monetization into each release

The Bigger Realization

This wasn't really about torrenting specifically. It was about noticing how much "free" software I'd been using that wasn't actually free of cost — just free of a price tag, while quietly monetizing my attention, my data, or my patience through ads and bundleware instead.

qBittorrent didn't change what I was downloading. It changed what I had to put up with to download it.

This is part of my "Everyday Open Source" series, where I highlight open-source tools that quietly make daily life better.

Try It Yourself

• Website: qbittorrent.org
• GitHub (source code): github.com/qbittorrent/qBittorrent
• Documentation / wiki: available on the project's GitHub wiki

Every time I needed something from it — a warranty for a broken appliance, a receipt for a tax deduction, a lease agreement from three apartments ago — I'd spend twenty minutes flipping through paper, muttering, before either finding it crumpled at the bottom or admitting defeat and calling customer support instead.

The breaking point was a doctor's note I needed for an insurance claim. I knew I had it. I knew it was somewhere in that drawer. I never found it.

The Obvious Fix, and Why It Wasn't Enough

The obvious answer was "scan everything." I did — for about two weeks. I ended up with a folder on my laptop called Scans containing 200 files named img_20230412_scan.pdf, img_20230412_scan(1).pdf, and so on. Searchable in name only, and the names told me nothing.

A pile of scanned paper is still a pile. I hadn't solved the problem — I'd just changed its file format.

Finding Paperless-ngx

I came across Paperless-ngx while looking for something that could do more than store scans — something that could actually understand what was in them. The pitch was simple: feed it documents, and it OCRs the text, extracts dates and tags, and makes everything genuinely searchable — not by filename, but by content.

Open source, self-hosted, no subscription. I was cautiously optimistic, mostly because I'd been burned before by tools promising "smart" organization that turned out to be a fancy folder structure in disguise.

Setting It Up

I ran Paperless-ngx on my home server alongside a couple of other self-hosted tools I already had going. The setup itself was straightforward — point it at a folder, and anything dropped into that folder gets automatically processed: OCR'd, tagged, and archived.

I fed it a test batch: a handful of old receipts, a lease agreement, one genuinely illegible handwritten note from a plumber. Within a minute, everything showed up in the web dashboard — not as a wall of thumbnails, but as searchable, tagged documents. I searched "plumber." The handwritten note came up. I searched a dollar amount from a receipt. That came up too.

That's when I realized this wasn't a scanning tool. It was a search engine for my paper life.

The Actual Migration

Over one long weekend, I went through the drawer. All of it. Every receipt, every warranty card, every form I'd been keeping "just in case." I fed it all through a document scanner into Paperless-ngx's watch folder and let it process overnight.

By the next morning, years of paper clutter had become a searchable archive. I could type "warranty" and see every warranty I owned, sorted by date. I could type a company name and pull up every receipt from them, ever. Tags got applied automatically based on rules I set — anything from my bank went into "Finance," anything with "lease" in it went into "Housing."

I shredded the physical originals I no longer needed to legally retain. The drawer that had mocked me for years now holds spare cables.

Where It Actually Helps Now

• Tax season: every relevant receipt and form, tagged and searchable by year, no digging

• Insurance claims: found that doctor's note in eight seconds instead of never

• Warranty lookups: search the product name, get the receipt and warranty card instantly

• New paperwork: mail gets scanned the day it arrives, filed automatically, original shredded within the week

The system runs quietly in the background now. New documents get dropped in, processed, tagged, archived. I don't think about it until I need something — and then it takes seconds, not twenty minutes of drawer archaeology.

What This Was Really About

It wasn't really about paper. It was about how much mental overhead I'd been carrying without noticing — a low hum of "where is that document, do I still have it, did I lose it" that I'd just accepted as normal for years.

Paperless-ngx didn't just digitize a drawer. It removed a small, persistent source of dread I didn't realize I'd been living with.

This is part of my "Everyday Open Source" series, where I highlight open-source tools that quietly make daily life better.

Try It Yourself

• Website / GitHub: github.com/paperless-ngx/paperless-ngx

• Documentation: docs.paperless-ngx.com

I remember thinking, half-relieved, half-uneasy: that's the app I use too.

I didn't leave that day. But the thought didn't leave either — the single most sensitive piece of software on my phone, the one holding literal keys to my email, my bank, my entire digital life, was sitting on a server I had no control over and no real visibility into.

Why I Kept Putting It Off

Password managers are one of those tools where "just switch" is easier said than done. Every login, every 2FA backup code, every secure note I'd built up over years — migrating that felt like performing surgery on my own digital life. So for a long time, I told myself the convenience was worth the risk.

Then I found out I didn't actually have to choose between the two.

Enter Vaultwarden

Vaultwarden is an open-source server that speaks the exact same language as Bitwarden — meaning it works with the official Bitwarden apps, browser extensions, and autofill, the same interface millions of people already use. The difference is where the vault actually lives.

Instead of your encrypted vault sitting on Bitwarden's cloud servers, it sits on hardware you control. Same apps. Same autofill. Same experience. Different owner.

I'd assumed self-hosting something like this would mean wrestling with servers, certificates, and cryptic config files for a weekend. It didn't. Vaultwarden is famously lightweight — built to run comfortably on something as small as a Raspberry Pi sitting in a closet.

Setting It Up

I already had a small home server running a few other self-hosted tools, so I added Vaultwarden as one more container. Within about twenty minutes — most of which was setting up a proper HTTPS certificate, not actually configuring Vaultwarden — I had a working vault server.

Then came the part I was dreading: migration. Bitwarden makes it almost anticlimactic. I exported my existing vault, pointed the official Bitwarden app at my new self-hosted server instead of Bitwarden's own servers, and imported everything back in. My passwords, my secure notes, my 2FA seeds — all there, all intact, just living somewhere I actually controlled.

The Feeling I Didn't Expect

I thought this would feel like a technical upgrade. It felt more like locking my own front door for the first time after years of leaving it open because "nothing had happened yet."

Every time I unlock my vault now, I know exactly where that encrypted data lives. Not "somewhere in a company's infrastructure I'll never see." A drive, in a box, in my own home, that I could physically point to if I wanted.

What Changed Day to Day

Honestly? Almost nothing, on the surface — and that's the best part.

• Autofill still works exactly the same, in every browser and app
• I still generate strong, unique passwords for every new account
• I still share select logins with my partner through the same sharing feature
• 2FA codes are stored right alongside the passwords, same as before

The only thing that changed is who's holding the vault. And unlike the official hosted version, Vaultwarden includes premium features like TOTP generation and vault sharing for free — no subscription tier gatekeeping them.

The Bigger Realization

This wasn't really about saving a subscription fee, even though I did. It was about noticing how easily I'd handed over the one piece of software that, if compromised, could unravel everything else — email, banking, social accounts, all of it — without ever really deciding to.

Vaultwarden didn't change what a password manager does. It changed who I was trusting to do it.

This is part of my "Everyday Open Source" series, where I highlight open-source tools that quietly make daily life better.

Try It Yourself

• Website / GitHub: github.com/dani-garcia/vaultwarden
• Compatible official apps: bitwarden.com/download
• Documentation / wiki: github.com/dani-garcia/vaultwarden/wiki

I was scrolling through Evernote's terms of service — something I'd never actually read in the five years I'd been using it — and found a line about how they could access account content to "improve their products." My journal entries. My half-formed ideas. My private to-do lists. All of it, technically, readable by someone other than me.

I closed the tab, opened a new note, and typed: find a new notes app.

The Search

My requirements were simple, or so I thought:

• My notes should be private. Actually private, not "we promise not to look" private.
• I shouldn't need to pay a subscription just to sync between my phone and laptop.
• I shouldn't be locked into a proprietary format that traps my years of notes if I ever want to leave.

Most apps I tried failed at least one of these. Notion was beautiful but fully cloud-based, no encryption, no way to self-host meaningfully. Standard Notes looked promising but felt limited for longer-form writing. A few others wanted a monthly fee just to sync past two devices — a fee to use my own notes on my own devices.

Then someone in a self-hosting forum mentioned Joplin, almost as an aside. "It's open source, encrypted, and syncs however you want." I almost scrolled past it. I'm glad I didn't.

First Impressions

Joplin looks unassuming — a clean, simple note-taking interface, markdown-based, nothing flashy. My first thought was, "this looks like a text editor with folders." My second thought, once I dug into the settings, was very different.

Every note can be end-to-end encrypted. Not "encrypted at rest on our servers" — encrypted before it ever leaves your device. Even if you sync through a cloud service, what lands on that server is unreadable without your key. Joplin's own maintainers, if they wanted to, couldn't read your notes.

And sync isn't locked to one company's infrastructure. You choose: Dropbox, OneDrive, a WebDAV server, Nextcloud, or even just a folder on your own machine. No forced subscription. No "upgrade to sync more than two devices."

The Migration

I exported my old notes and imported them into Joplin — plain markdown files, nothing proprietary to fight against. That alone was a small revelation. My notes weren't trapped in someone's database format anymore; they were just... files. Text I could read in any editor, forever, regardless of what happened to any app.

I set sync to a private Nextcloud folder I already had running, turned on encryption, and installed the mobile app. Within minutes, my phone and laptop were talking to each other — through infrastructure I controlled, in a format only I could read.

Where It Actually Changed Things

A few weeks in, I noticed something: I started writing more honestly.

That sounds small, but it wasn't. I'd been subconsciously self-censoring my own notes app for years — never quite writing that year's messy goals, that half-formed business idea, that private journal entry, because some part of me knew a company's server was involved somewhere. Once I trusted the notes were actually mine, I stopped holding back.

I also started using the web clipper more than I expected. Research articles, recipes, technical docs — clipped straight into an encrypted, searchable archive I own, instead of forty browser tabs I'd never revisit.

What My Setup Looks Like Now

• Daily journal, encrypted, synced across phone and laptop
• A running knowledge base of technical notes, all in markdown
• Clipped articles and references, tagged and searchable
• Zero monthly fee — sync runs through a Nextcloud instance I already had
• If I ever want to leave, my notes walk out the door with me as plain text files, not locked behind an export button that half-works

The Part That Stuck With Me

What got me thinking wasn't really about note-taking software. It was realizing how much of my daily thinking — literal, unfiltered thoughts — had been passing through a company's servers without me ever deciding that should be the case. It wasn't a conscious choice. It was just the default I'd never questioned.

Joplin didn't just give me a new app. It gave me back the assumption that my own notes should, by default, be mine.

This is part of my "Everyday Open Source" series, where I highlight open-source tools that quietly make daily life better.

Try It Yourself

• Website: joplinapp.org
• GitHub (source code): github.com/laurent22/joplin
• Documentation: joplinapp.org/help
• Mobile apps: available on the App Store and Google Play

"You've used 98% of your storage. Upgrade to Google One for more space."

I had 40GB of my own photos, notes, and project files — sitting on my own laptop, my own phone, my own home server — and a company was asking me to pay rent to move data between my own devices. That's when it hit me: I wasn't paying for storage. I was paying for a middleman.

So I went looking for a way out.

The Realization

Here's the thing about cloud sync services like Google Drive, Dropbox, or OneDrive: your file doesn't go directly from your laptop to your phone. It goes laptop → their server → phone. Every sync, every backup, every "your document has been updated," passes through a company's infrastructure first.

That's convenient. It's also a subscription, a privacy trade-off, and a single point of failure, all rolled into one.

I didn't need a cloud. I needed my devices to talk to each other.

Enter Syncthing

A friend mentioned an open-source tool called Syncthing, and the concept sounded almost too simple to be real: it syncs folders directly between your devices, peer-to-peer, with no central server storing your data.

No account. No subscription. No company sitting in the middle reading your file metadata.

I was skeptical. Google Drive had been my default for years — it just worked, and it was already synced across every device I owned. Every "no cloud needed" tool I'd tried before was either half-finished or required a computer science degree to configure. So I gave myself one evening to set it up before giving up on the idea entirely.

Setting It Up

I installed Syncthing on my laptop first — a lightweight app that opens a simple web dashboard in your browser. Then I installed it on my Android phone.

The moment that sold me: each device gets a unique ID, like a fingerprint. To connect two devices, you just enter one device's ID into the other. That's it. No login, no email, no "create an account to continue."

I shared my Documents folder from my laptop, added my phone as a connected device, and watched the dashboard.

Files started appearing on my phone. Live. In real time. No middle server. No waiting for an "upload" to finish and then a "download" to start somewhere else. Just two devices, quietly talking to each other over the network.

The Moment It Clicked

A few days later, I was on a train, no wifi, phone on mobile data. I edited a note in my notes app. When I got home and connected to my home network, my laptop picked up the change within seconds — because Syncthing had queued the update and pushed it the moment both devices were reachable again.

That's when I stopped thinking of it as "a Dropbox alternative" and started thinking of it as something more fundamental: my devices had their own private network, and I was the only one on it.

I added my home server next. Now my phone photos land there automatically. Not on someone else's cloud — on a drive sitting in my closet.

What Changed

A few months in, here's what my setup actually looks like:

• My laptop and phone stay in sync automatically — documents, notes, work files
• My phone's camera roll backs up to my home server the second I'm on wifi
• My partner and I share a folder for household files, synced directly between our two laptops
• Zero monthly fees. Zero storage limits beyond what my own drives can hold
• If Syncthing's company disappeared tomorrow, my setup wouldn't break — the protocol is open, and my files are just... files, on my own drives

I didn't just save money. I got my files back.

Why It's Not "For Everyone" — Yet

I won't pretend it's a total 1:1 Google Drive replacement. Real-time collaborative editing (like Google Docs), sharing a public link to a stranger, or accessing files from a browser on a random computer — Syncthing doesn't do those things. It's built for syncing between devices you control, not for broadcasting to the world.

But for the actual daily task most of us use cloud sync for — keeping our own laptop, phone, and home server in agreement — it does the job without asking anything in return.

The Bigger Lesson

What stuck with me wasn't really about file syncing. It was the pattern I noticed once I started looking: how many everyday conveniences quietly rely on data passing through someone else's server, when the two devices doing the actual talking are both sitting right there, already trusting each other.

Syncthing just cut out the middleman I never needed in the first place.

Try It Yourself

• Website: syncthing.net
• GitHub (source code): github.com/syncthing/syncthing
• Documentation: docs.syncthing.net
• Android app: available on F-Droid and Google Play

Here's what each one actually does.

1. The Native App (Desktop/Laptop Application)

This is the full VPN client — the one with a big power button UI that most providers push you toward installing first.

What it covers: Every app and process on your device, system-wide. Your browser, your torrent client, your email app, background updates, everything. Once it's on, all outgoing traffic from the machine routes through the VPN's encrypted tunnel.

How it works: It typically creates a virtual network adapter at the OS level and reroutes your entire network stack through it, usually using protocols like WireGuard, OpenVPN, or IKEv2.

When to use it:

• You want full-device protection, not just browser traffic.
• You're on public Wi-Fi and want everything — not just your browsing — encrypted.
• You use apps outside the browser that need protection too (games, torrent clients, other software).

Trade-off: It's heavier. Full-tunnel encryption adds more overhead than encrypting just browser traffic, and depending on the protocol and server load, you'll usually notice more of a speed hit than with a lighter extension.

2. The Browser Extension

This is a much lighter tool that only touches traffic going through that specific browser.

What it covers: Only the browser it's installed in. If you open a different browser, a separate app, or a background service, none of that traffic goes through the VPN. Some "VPN" browser extensions aren't even a true VPN — many are actually just an encrypted proxy for that browser's traffic, which is a meaningfully different thing from a full VPN tunnel.

How it works: It reroutes the browser's HTTP/HTTPS requests through a remote server, often via a proxy protocol rather than a full network-level tunnel.

When to use it:

• Quick geo-unblocking for browser-based streaming or content.
• Lightweight browsing privacy without wanting to reroute your entire device.
• You don't want the performance overhead of encrypting non-browser traffic you don't care about.

Trade-off: Weaker protection. If you're using it and think your whole device is now anonymized, it isn't. Apps outside the browser, DNS requests made by the OS, and other background traffic aren't covered.

3. Built-In OS/System VPN Settings

Every major OS — Windows, macOS, iOS, Android — has a native VPN configuration screen buried in system settings. This isn't a separate product; it's the OS providing a slot to plug a VPN connection into using standard protocols.

What it covers: System-wide, just like the native app — but without the provider's extra software, UI, or built-in features like a kill switch, split tunneling controls, or ad blocking.

How it works: You manually enter server details, protocol, and credentials your VPN provider gives you (or an "on-demand" config file), and the OS handles the connection itself using its built-in VPN protocol support, without needing the vendor's app running in the background.

When to use it:

• Devices where you can't or don't want to install a third-party app (some work devices, routers, smart TVs, or lightweight system installs).
• You want a lighter-footprint connection without the extra app running in the background.
• Setting up a VPN on your home router, so every device on the network is covered without installing anything on each one individually.

Trade-off: No extra features. No kill switch, no split-tunneling UI, no automatic server selection — you get the raw encrypted tunnel and nothing else. If your connection drops, most system-level setups won't automatically block traffic the way a dedicated app's kill switch does.

Quick Comparison

Which One Should You Actually Use?

If you want real protection — banking on public Wi-Fi, hiding your traffic from your ISP, anonymizing everything you do — use the native app. It's built for that job and includes safety nets like a kill switch that the other two don't have.

If you just want to watch a show that's geo-blocked or don't want your browsing history tied to your IP for casual browsing, the extension is lighter and good enough for that narrow job — just don't mistake it for full protection.

Use the system-level setup when you're configuring a device that can't run the provider's app, or when you want one VPN connection to cover an entire router's worth of devices at once.

They're not competing options — they're different tools solving different-sized problems. The mistake is assuming any one of them does what the others do.

I ran into exactly this problem trying to keep a work profile separate from my personal one on a phone that had no native way to do it. That's what led me to Island, and this is a breakdown of what it actually does, where it's genuinely useful, and where it isn't.

What Island Actually Is

Island is a free, open-source Android app built by developer Oasis Feng. Instead of faking a clone the way some third-party "parallel space" apps do, it lets you clone an app for parallel running, freeze an app to block its background activity, and hide an app entirely. It does this by creating a genuine work profile on your device — the same underlying Android infrastructure Google built for enterprise device management, repurposed here for personal use.

Because it rides on Android's real managed-profile system rather than a hack, Island creates a separate space for apps within the work profile, keeping them isolated from your main profile and its data. Anything you put inside that space — a second WhatsApp, a work Gmail, a banking app you don't fully trust — runs in its own sandbox with its own storage and permissions.

Why This Matters on "Unsupported" Phones

If your device doesn't have a native dual-app feature, Island effectively builds one for you using standard Android APIs, which is why it works across a much wider range of devices than manufacturer-specific tools. There's one important caveat worth knowing before you install it: if your device already has "Dual Apps," "App Twin," or a similar feature, it may be built on the same underlying infrastructure as Island, which causes a conflict — meaning you can't run both at once. In other words, Island isn't meant to stack on top of a native dual-app feature; it's meant to replace the need for one.

What You Can Actually Do With It

• Run two accounts of the same app — a personal and work WhatsApp, two Gmail logins, dual gaming accounts — without needing separate physical devices.
• Freeze apps so they stop running in the background entirely, which is handy for battery life or apps you rarely use but don't want to uninstall.
• Hide apps from your main launcher and app drawer for privacy.
• Split VPN usage — you can run a VPN only on one side, or run different VPNs on each side, which is genuinely useful if you want your work profile routed differently than your personal one.
• Keep personal data boundaries intact — apps inside the Island space can't see your contacts, call history, or photos from outside it.

The Trade-offs

Island isn't magic, and it's worth going in with realistic expectations:

• Setup has a learning curve. You're creating a work profile, which is a heavier concept than just tapping "clone app" in a manufacturer's settings menu.
• Some apps behave differently inside it. A handful of apps detect they're in a managed/work profile and restrict certain features.
• Extra battery and resource use. Running a second instance of an app means the OS is genuinely managing two live profiles, not a lightweight fake.
• Uninstalling isn't a simple drag-to-trash. You need to destroy the Island space from within the app first, or manually remove the work profile from your system settings if you've already deleted the app.

The Personal-vs-Work Case

One of the most practical reasons to use Island has nothing to do with running two accounts of the same app — it's keeping your personal and work life on separate profiles entirely.

If you use one phone for both, putting your work apps (email, Slack, VPN client, whatever your employer requires) inside the Island space means:

• Your employer's mobile device management, if any, stays contained to that profile — it can't see your personal photos, messages, or browsing.
• You can wipe the entire work profile in one tap if you leave the job, without touching your personal data.
• Notifications, storage, and background activity for work apps stay separate from your personal phone experience, so work doesn't quietly drain your personal battery or clutter your main app drawer.
• If your company ever asks to install a management profile on your device, Island's work-profile approach is the same underlying mechanism, so you're not fighting the system — you're using it on your own terms before someone else does it for you.

It's less flashy than running two Instagram accounts, but for a lot of people, this is the actual use case that makes Island worth installing in the first place.

Who Should Actually Use It

If you're someone who needs two accounts on one app — a side hustle Instagram, a second WhatsApp number, separating work and personal messaging — and your phone manufacturer never gave you that option, Island is one of the few tools that solves this properly instead of with a shady clone APK. It's open source, it's actively maintained, and it uses Android's own framework instead of fighting against it.

It's not the flashiest app on your home screen. But it's quietly one of the more useful ones if you've ever needed "just one more" instance of something your phone wasn't built to give you.

Heads Up: Island's Managed Mainland Mode (Beta) — Proceed With Caution

If you go digging through Island's settings, you might come across a feature called Managed Mainland. It's currently in closed beta, and it's worth knowing what it does before you touch it.

A few things to keep in mind:

• Order matters. Once Managed Mainland is activated, you can no longer create a new Island space afterward. If you want to use both, set up Island first.
• Older devices lose cloud backup. On Android versions prior to 7.1, app backup (like Google Drive backup for app data) stops working entirely under this mode. Android 7.1 and newer are unaffected.
• It's manual setup only — there's no streamlined in-app flow for it yet.

And the developer's own disclaimer is blunt about the risk:

This beta version may be dangerous on some Android devices, it may cause boot-loop and even brick your device. The purpose of closed beta exclusive for advanced users is to widely test and improve the device compatibility. Don't install it on your daily device and remember to BACKUP FIRST.

In plain terms: this isn't a feature for casual users, and it's not something to try on the phone you actually depend on. If you're curious and want to help test device compatibility, use a spare device and back up first. For everyone else, the standard Island setup covered above is the stable, safe path — Managed Mainland is optional territory for advanced users only.

Get It Here

Island is available on the Google Play Store, and since it's open source, you can also find the source code and setup docs on the developer's official site at island.oasisfeng.com. If you'd rather avoid Google Play Services entirely, there's a fully FOSS fork called Insular available through F-Droid with the same core functionality.

If your device already has a native "Dual Apps" feature, check the FAQ on the official site first — it explains the conflict mentioned earlier and how to work around it.

Sound familiar?

The Problem Nobody Warns You About

Everyone tells you "just contribute to open source" like it's as simple as walking into a library and picking a book. Nobody mentions that GitHub has over 400 million repositories, that half of them are abandoned side projects from 2019, and that finding a project that's both alive and welcoming feels like searching for a specific grain of sand on a beach.

I spent weeks doing what I now call "tourist browsing" — clicking into trending repos, admiring the code, feeling intimidated, and closing the tab. I wasn't finding projects. I was window shopping.

The breaking point came on a Tuesday night when I opened yet another "awesome" repo with 30k stars, found an issue that looked approachable, and discovered it had 40 comments of people asking if it was already taken. Nobody had touched it in eight months.

The Small Trick That Changed Everything

A friend who'd been contributing to open source for years watched me doing this and asked one question: "Why are you searching for projects? Search for issues."

It sounds obvious in hindsight, but it rewired how I approached the whole thing. Instead of asking "what project should I join," I started asking "what specific, well-described problem can I solve this weekend?"

I typed this into GitHub's search bar:

label:"good first issue" language:python state:open

Instead of 400 million repositories, I had a filtered list of actual tasks, written by maintainers who wanted newcomers specifically. The whole frame shifted — I wasn't auditioning for a project, I was picking a task off a job board.

The Project That Actually Stuck

The issue I picked wasn't glamorous. It was a documentation fix in a mid-sized CLI tool — maybe 2,000 stars, nothing trending. But three things were true about it:

• The maintainer had replied to an issue two days earlier.
• There was a CONTRIBUTING.md that actually explained the setup, not just a wall of boilerplate.
• The last ten pull requests had all been merged within a week.

None of that is exciting to read about. But it's the entire difference between a contribution that goes somewhere and one that dies in review purgatory.

I submitted the fix. The maintainer merged it in two days and left a comment: "Thanks, want to try the next one?" That single sentence did more for my motivation than any "awesome open source" list ever had.

The Real Lesson

I'm not going to pretend that one merged PR turned me into a seasoned open source contributor overnight. But it did change how I think about the search itself.

The lesson wasn't "find the right project." It was: stop treating GitHub like a museum and start treating it like a job board. Filter by labels. Check who actually responds. Pick something unglamorous with a maintainer who replies. The rest takes care of itself, one issue at a time.

If you're stuck in the tourist-browsing phase right now — go run that label search. It's a smaller trick than it sounds, and it's the only reason I stopped collecting tabs and started collecting merged PRs.

What if a normal-looking image could carry a private message without adding another file or interface to the conversation?

That question led me to build ImgSteganoBot, a Telegram bot that encodes text into images and later decodes it with a security code. The project combines Telegram's conversational interface with Azure Functions, Azure Blob Storage, and image-processing logic based on histogram shifting.

(GitHub: deebadithya/ImageStegnoBot)

The user experience

The bot is designed around a short conversation:

1. Send /encode and provide the text to hide.
2. Upload an image as a document so Telegram preserves the original bytes.
3. Receive an encoded image and a generated security code.
4. Send /decode, provide the code, and upload the encoded image.
5. The bot extracts and returns the hidden message.

The command flow keeps the interaction approachable. Users do not need to learn a command-line tool or manage a separate web application.

How it works

The Azure Function receives Telegram webhook updates over HTTP and passes them to the bot handlers. During encoding, the image-processing module converts the message into binary data and embeds it in the image. During decoding, the same process reads the hidden data and reconstructs the original text.

Telegram → Azure Function (webhook + handlers)
                   │
        ┌──────────┴──────────┐
        ▼                     ▼
Image processing        Blob Storage
(encode / decode)       (temp image files)

Generated identifiers give output files unique names, while Azure Blob Storage provides a place to upload and retrieve image data when the workflow needs persistent storage.

One practical detail matters here: images sent as compressed photos can lose pixel information. The current bot therefore asks users to send images as documents, which helps preserve the data required for reliable decoding. Direct photo handling is an area for future improvement.

Security lessons

The first version stored the Telegram token, webhook authorization code, and Azure Storage credentials directly in source code. That is convenient during a prototype, but dangerous as soon as the project is shared or pushed to a repository.

# .env.example
TELEGRAM_BOT_TOKEN=
WEBHOOK_AUTH_CODE=
AZURE_STORAGE_CONNECTION_STRING=

The project now reads these values from environment variables instead. A checked-in .env.example documents the required names without containing live credentials.

In a real deployment, secrets should be configured through Azure Function App settings or a managed secret store, and any credentials that were previously exposed should be rotated immediately.

What I learned

This project taught me that a useful security tool is as much about workflow design as algorithms. Preserving image bytes, guiding users through each step, cleaning up temporary chat messages, and handling deployment configuration all affect whether the core technique works in practice.

The next steps are to:

• Improve direct photo support without losing pixel data
• Isolate conversation state per Telegram user
• Add automated tests for round-trip encoding and decoding
• Replace shared storage credentials with managed identity where possible

ImgSteganoBot is a small project, but it sits at an interesting intersection of messaging, cloud functions, and information hiding. It has been a practical way to explore how an image-processing idea becomes a usable service.

Code: github.com/deebadithya/ImageStegnoBot

A practical case study of building a personal stock-monitoring dashboard with watchlists, intraday charts, JWT authentication, and a server-side data layer.

Published: May-June 2024

Stock dashboards often begin with a simple question: “What are the assets I care about doing right now?” The difficult part is turning that question into a useful product. A good dashboard needs more than an API call. It needs authentication, user-specific state, sensible caching, clear visualisation, and an interface that makes repeated monitoring easy.

That was the motivation behind TrackSto, a full-stack stock tracking and monitoring web application. Users can register, sign in, search a catalogue of symbols, add stocks to a personal watchlist, and inspect intraday values through an interactive line chart.

This article explains how the project is structured, how data moves through the system, and what I learned while building it.

What TrackSto does

TrackSto focuses on a small but complete monitoring workflow:

• A user creates an account and logs in.
• The frontend stores the JWT access and refresh tokens locally.
• Authenticated requests automatically include the access token.
• The user searches a local symbol catalogue by ticker.
• A selected symbol is saved to that user's watchlist.
• The backend retrieves intraday data from Alpha Vantage when needed.
• The response is stored in a local daily cache file to avoid repeated requests.
• The dashboard displays the latest values in a table.
• The user selects a watchlist symbol and chooses Open, High, Low, Close, or Volume for the chart.

The result is a focused monitoring tool rather than a trading platform. It is designed to make a user's preferred symbols easy to revisit and compare.

Technology choices

Frontend

• React 18
• React Router for navigation and protected routes
• Material UI for layout, controls, authentication screens, and the data grid
• Nivo Line for the interactive time-series chart
• Axios for API communication
• jwt-decode for checking access-token expiry in the browser

Backend

• Django 5
• Django REST Framework
• SQLite for user and watchlist persistence
• SimpleJWT for access and refresh tokens
• django-cors-headers for controlled frontend-to-backend requests
• requests for Alpha Vantage calls

Data provider

TrackSto uses Alpha Vantage's TIME_SERIES_INTRADAY endpoint with a five-minute interval. The frontend receives the provider response through Django instead of calling Alpha Vantage directly. This keeps the external API integration in one place and prevents the browser from becoming responsible for provider credentials and request policy.

High-level architecture

The application is split into two independently runnable projects:

TrackSto/
├── backend/
│   ├── manage.py
│   ├── stocktrack/
│   │   ├── settings.py
│   │   └── urls.py
│   └── stockapp/
│       ├── models.py
│       ├── serializers.py
│       ├── views.py
│       └── urls.py
└── frontened/
    ├── package.json
    └── src/
        ├── api.js
        ├── App.js
        ├── components/
        ├── global/
        └── pages/

The browser talks to Django through Axios. Django owns authentication, user-specific watchlists, and the Alpha Vantage integration. The database stores the relationship between a user and a symbol, while the current implementation stores fetched market responses in temp_storage.json as a date-based cache.

Designing the watchlist model

The core database model is intentionally small:

class WatchList(models.Model):
    symbol = models.CharField(max_length=10)
    author = models.ForeignKey(
        User,
        on_delete=models.CASCADE,
        related_name="watchlist",
    )

A watchlist entry belongs to a Django user. That ownership relationship is important: the same symbol can appear in many users' watchlists, but each user should only receive their own entries.

The list endpoint filters by the authenticated request user:

def get_queryset(self):
    return WatchList.objects.filter(author=self.request.user)

When a new item is created, the backend assigns the author from the token rather than trusting a user-supplied request field:

def perform_create(self, serializer):
    serializer.save(author=self.request.user)

This is a useful general rule for multi-user applications: identity and ownership should come from the authenticated request context whenever possible.

Authentication with JWT

The backend exposes three important authentication routes:

POST /api/user/register/
POST /api/token/
POST /api/token/refresh/

The registration serializer uses Django's create_user method, so passwords are hashed by Django instead of being saved as plain text.

On the frontend, the Axios instance adds the access token to every outgoing request:

api.interceptors.request.use((config) => {
  const token = localStorage.getItem(ACCESS_TOKEN);

  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }

  return config;
});

The ProtectedRoute component decodes the token, checks its expiry, and attempts to refresh it before allowing the dashboard to render. This keeps unauthenticated users away from the main application route while still supporting short-lived access tokens.

Keeping Alpha Vantage behind the backend

The dashboard does not call Alpha Vantage directly. Instead, the watchlist API fetches data for the user's symbols and converts it into a response keyed by symbol.

The provider request uses the intraday endpoint:

url = (
    "https://www.alphavantage.co/query"
    f"?function=TIME_SERIES_INTRADAY"
    f"&symbol={symbol}"
    f"&interval=5min"
    f"&apikey={api_key}"
)

The response contains a time-series object whose fields look like this:

{
  "2024-06-20 15:55:00": {
    "1. open": "184.20",
    "2. high": "184.55",
    "3. low": "184.10",
    "4. close": "184.40",
    "5. volume": "123456"
  }
}

The backend checks temp_storage.json before making a new request. If the symbol was already fetched on the current date, the stored response is returned. If the cached date is older, the application requests fresh data and replaces the cached entry.

This approach reduces duplicate requests during a development session and helps avoid Alpha Vantage rate limits. It is a simple daily cache rather than a full market-data storage system, but it is enough for the first version of the product.

Building the dashboard

The dashboard combines three primary areas:

1. A top bar with the TrackSto logo, symbol autocomplete, and the account menu.
2. A chart area with symbol selection and a field selector.
3. A Material UI data grid containing the user's watchlist and recent values.

The autocomplete uses a bundled symbol catalogue containing ticker symbols and descriptions. Selecting an item triggers a POST request to the watchlist endpoint. Duplicate symbols are ignored on the client before the request is sent.

The dashboard maps friendly labels to Alpha Vantage's response keys:

const columns = {
  Open: "1. open",
  Close: "4. close",
  Volume: "5. volume",
  Low: "3. low",
  High: "2. high",
};

That mapping keeps the interface readable while still allowing the chart component to consume the provider's original field names.

Transforming data for Nivo

Nivo expects a series with id and data fields, while Alpha Vantage returns a dictionary keyed by timestamp. The chart component bridges those two formats:

const transformData = (chartMeta, key) => {
  const timeSeries = chartMeta["Time Series (5min)"];
  const data = [];

  for (const timestamp in timeSeries) {
    data.push({
      x: new Date(timestamp),
      y: parseFloat(timeSeries[timestamp][key]),
    });
  }

  return [{ id: key, data: data.reverse() }];
};

The chart uses a time scale, formats the horizontal axis as hours and minutes, enables a mesh for easier hover interactions, and displays points along the line. Reversing the entries gives the chart chronological order even though the API response is returned newest-first.

The selected field changes the key passed into the chart. That makes one chart component reusable for Open, High, Low, Close, and Volume instead of creating a separate component for each metric.

The request flow

When a user opens the dashboard, the main flow looks like this:

React Dashboard
    |
    | GET /api/watchlist/
    v
Django WatchListCreate
    |
    | Filter WatchList rows by request.user
    v
For each symbol:
    |-- return today's temp_storage.json entry
    |-- or request Alpha Vantage and cache the response
    v
Processed JSON keyed by ticker
    |
    v
DataGrid + Nivo Line Chart

When a user removes a symbol, the frontend sends a DELETE request using the watchlist row's database ID. After a successful response, it reloads the watchlist so the grid and chart selector stay synchronized with the server.

Running the project locally

Backend

From the backend directory, create and activate a virtual environment, install Django, Django REST Framework, SimpleJWT, CORS headers, Requests, and dotenv, then run migrations:

python -m venv .venv
.venv\Scripts\activate
pip install django djangorestframework djangorestframework-simplejwt django-cors-headers requests python-dotenv
python manage.py migrate
python manage.py runserver

The API runs at http://127.0.0.1:8000 by default.

Frontend

From the frontened directory:

npm install
npm start

The React development server runs at http://localhost:3000. The frontend API base URL should point to the Django server through the project's environment configuration.

What I learned

1. A small data model can support a useful product

The watchlist only needs a symbol and an owner, but that simple relationship enables registration, personalized state, filtering, and deletion. Starting with a focused model made it easier to build the complete workflow before adding more market features.

2. Caching belongs near the external integration

The frontend should not need to know whether data came from Alpha Vantage or a local cache. Keeping that decision in the backend made the UI simpler and gave the server one place to control provider traffic.

3. Data visualisation is mostly data preparation

The chart library was not the hardest part. The important work was converting timestamp-keyed API data into the series format the chart expected, parsing values as numbers, and giving users a meaningful time axis.

4. Authentication is a system concern

Protecting a page is not enough. The API must filter data by the authenticated user, the serializer must avoid accepting ownership from the client, and the frontend must handle token expiry. The watchlist endpoint demonstrates how these layers work together.

Production improvements

The project is a functional learning application, but I would make several changes before deploying it publicly:

• Move the Alpha Vantage key into an environment variable and rotate the exposed development key.
• Replace the JSON cache with a database-backed cache or Redis so multiple processes can share it safely.
• Add a uniqueness constraint on (author, symbol) to prevent duplicate rows under concurrent requests.
• Use IsAuthenticated for the delete endpoint instead of allowing anonymous access at the view level.
• Fix the refresh-token request to send the actual token value from local storage.
• Store tokens in a more defensive browser strategy, such as secure, HttpOnly cookies where the deployment architecture allows it.
• Add validation for malformed symbols and provider error responses.
• Add automated tests for registration, token access, watchlist ownership, duplicate symbols, deletion, and cache expiry.
• Move Alpha Vantage requests out of the list serializer path if the application grows, using a scheduled job or background worker.

These improvements are not just polish. They address credential safety, concurrency, authorization, resilience, and maintainability.

Final thoughts

TrackSto started as a stock information dashboard and became a compact full-stack exercise in user-specific data, authentication, API integration, caching, and visualisation. React and Material UI made it possible to build the interface quickly, while Django REST Framework provided a clear place to enforce ownership and keep the external stock provider behind the server.

The most valuable part of the project was learning how these concerns connect. A chart is only useful when the data is current. Current data is only practical when requests are controlled. A watchlist is only personal when the API enforces ownership. And all of it needs an interface that makes the next decision obvious.

That combination is what turned TrackSto from a stock API experiment into a usable monitoring application.

Tags: react, django, python, web-development, javascript

Suggested Hashnode excerpt:

Learn how I built TrackSto, a full-stack stock monitoring dashboard with React, Material UI, Django REST Framework, JWT authentication, Alpha Vantage intraday data, personal watchlists, daily caching, and interactive Nivo charts.