DEV Community: Abdul Rafay

dotenv-vault Is Deprecated — Here's Your Migration Path

Abdul Rafay — Mon, 20 Jul 2026 09:39:11 +0000

If your team syncs environment variables with dotenv-vault, you've probably seen the notices by now: the project is deprecated. The .env.vault file format is officially marked deprecated, dotenv-vault-core has pointed users elsewhere for a while, and active development has moved to dotenvx — built by Mot, the same developer who created the original dotenv.

Nothing is going to break tomorrow. But building on a deprecated secrets format is a slow leak: no fixes, no new integrations, and every new teammate asking "wait, why are we using this?" Here's an honest map of where to go.

What you actually lose

dotenv-vault did three jobs:

Encrypted your .env files into a .env.vault file you could commit
Synced them across the team through dotenv.org
Separated environments (development, staging, production) with one key each

Any replacement needs to cover those three jobs — and ideally fix the things that were always awkward: key distribution still happened out-of-band, there was no per-person access control, and no record of who read what.

Option 1: dotenvx (the official successor)

dotenvx is the path the dotenv creator recommends, and there's an official migration extension for converting .env.vault files.

Its model: encrypted .env files live in your repo, decrypted at runtime with a private key. It's free, open source, works with any language, and requires no account.

Where it fits: solo developers and teams comfortable with encrypted-files-in-git. Where it doesn't: the private key still has to reach every teammate and every CI job through some other channel — which for most small teams means it gets pasted into Slack, the exact problem you were trying to solve. There's also no per-person access control and no audit trail; whoever holds the key holds everything.

Option 2: hosted secrets managers (Doppler, Infisical)

Both are mature, both solve team sync properly, both price per seat — Doppler's Team plan runs $21/user/month, Infisical's Pro is $18/identity/month where machines count as identities too. For a six-person team that's $1,300–1,500 a year, and machine identities push it higher. We keep honest comparisons of both, including where they beat us: Envpilot vs Doppler and Envpilot vs Infisical.

Option 3: Envpilot (what we built)

Envpilot is an open-source (MIT) environment variable manager built for exactly the team that used dotenv-vault: small, moving fast, no dedicated ops person.

No files in the repo at all. envpilot run -- npm run dev injects variables straight into the process; nothing secret touches disk.
Team sync with actual access control — role-based, per-variable permissions, and an audit log of who read what, when, from where.
Per-environment values with enforced key uniqueness — DATABASE_URL for development and production are separate variables that can never silently collide.
Flat pricing. Free for 3 teammates and 3 projects; the paid tier is one flat price per organization, not per seat. Adding your seventh developer costs nothing.
Encrypted in a dedicated vault — our database stores only reference IDs, never plaintext secret values. The whole platform is MIT-licensed on GitHub, so you can read exactly how that works.

The 10-minute migration

You don't need to convert your .env.vault file — you need the decrypted values you already have locally.

# 1. Install and sign in (browser SSO, no API keys in shell history)
npm install -g @envpilot/cli
envpilot login

# 2. Link the project folder
envpilot init

# 3. Push your existing .env into an environment
envpilot push --env development
envpilot push --env production --file .env.production

# 4. Verify, then delete the files
envpilot run -- npm run dev
rm .env .env.production .env.vault .env.keys

Teammates run steps 1–2 and they're synced — no key to hand them, because access is tied to their account, not a shared secret. When someone leaves the team, you revoke the person, not rotate every key they ever touched.

CI needs variables too: the GitHub Action pulls them with a scoped token and masks every value in workflow logs.

Which one should you pick?

Honest version: if you're solo and like the encrypted-files-in-git model, dotenvx is free and official — use it. If you're an enterprise with compliance requirements and budget, Doppler and Infisical are proven. If you're a small team that mostly wants to stop pasting .env files into Slack and know who touched what, that's the exact gap we built Envpilot for — and the free tier covers a 3-person team end to end, no credit card.

Idea Code App: My Build Story

Abdul Rafay — Fri, 28 Mar 2025 09:49:06 +0000

Alright, let's hear it. We've all been there—you have an idea for an app that could help you out, and you realize it could help others as well. But you don’t know how to create a good application, or moreover, you have no idea how to build one.

Now, you go on YouTube and start searching, and the number of videos is overwhelming. You watch one, then two, but when it comes down to actually starting from nothing, things start to get a little rough.

You don’t know the app flow, how users will interact with it, or even what features you need. And that’s perfectly normal. As a beginner trying to build an app, you don’t yet understand how things should flow.

The purpose of this blog post is to show you all how to build an app from scratch. I’ll go through everything—from the idea to development, all the bugs I encountered, how to solve them, and how AI can be helpful.

The Idea?

For this app, I was writing my notes on a website and could access them via the web. But what about mobile? It was really inconvenient to open a browser, enter a URL, and then visit my notes. And sometimes, the internet isn’t reliable. So, now what?

The solution for me was simple—I needed an app where I could read all my lecture notes with offline access.

With that in mind, I started writing down what I needed. The core idea was that I should be able to read my notes without an internet connection. My website already has API access, so I could call that API and render the content in the app, right?

It’s simple and can be done.

The Features

Once the core idea was set, it was time to think about what features would support it and ensure the app wasn’t misused. So, I added these features:

Offline & Online Access
Auth System
Color Choices
Note-Taking

These features would make note reading much smoother and more convenient.

Tech Stack

Once you have all the features listed and know what you want, the next step is choosing a good tech stack. People say it doesn’t matter what tech stack you choose, but let me tell you—when it comes to apps, you generally have four options for the frontend:

Flutter
React Native
Java (Android)
Swift (iOS)

And for the backend, there are several good options:

Firebase
Supabase
Appwrite
PocketBase

All of these options have their own pros and cons. If you’d like to see a core difference between Firebase and Supabase, check out my previous blog post.

I haven’t used PocketBase or Appwrite yet, but I’ve heard they are good options.

My Choice

For me, I’ll be using Flutter for the UI and Appwrite for the backend. The backend will handle user sync, note-taking, user authentication, and the auth gate—nothing more than that. The UI will be coded using Flutter because I use Flutter for everything, and I love its flexibility.

Your Choice

Don’t choose blindly—do your research and pick what makes you comfortable and what you feel confident coding in. If I weren’t used to Flutter, I would have gone with React Native, since I know how React works but have no experience with React Native. So, choose what works best for you.

Defining The Flow

You know the features, you know how to choose a tech stack, now it's time to define the flow. By flow, I mean how the user will navigate from one page to another. And this is actually very simple. When a user installs your application, what will they see first? It could be a Login Screen, an Introduction Screen, a Splash Screen, anything—it all depends on your thought process and your application.

Here’s the flow I created for my application:

The Auth Flow

The auth flow shows how the authentication process is handled in the app.

Login Flow

Installed -> Introduction Screen -> Login -> Success -> Home Screen
Installed -> Introduction Screen -> Login -> Failed -> Error Message

Register Flow

Installed -> Introduction Screen -> Register -> User Created -> Login -> Success -> Home Screen
Installed -> Introduction Screen -> Register -> User NOT Created -> Error Message

Auth Gate

User Logged In -> Home Screen
User Not Logged In -> Login Screen

Note Fetching Feature

This flow illustrates how the app operates under the hood.

Getting Notes via API

App Opened -> Internet Connection -> Call API (Get Data) -> Store in Local Database -> Show to User
App Opened -> NO Internet Connection -> Switch to Offline Mode

Taking Notes

Open App -> Switch to Note-Taking UI -> Create Note -> Write Some Content -> Save Content

Flow Thoughts

You can see how the app flow is structured. This is just the beginning. As you add more features, you’ll naturally have more flows to define. It’s better to set up a structure early and start coding, because as you develop, the flow will reveal itself more clearly.

I’m only able to describe this flow because I’ve actually done it—I’ve built the app, faced real challenges, and figured out how each UI should connect to the next.

Coding

Okay, you have everything set up. Now what? This is the question most people don’t know how to answer. You’ve got the design, the flow, the idea, and the tech stack. What’s next?

Here’s the short answer: Google and use AI.

In the beginning, Google a lot. Don’t just rely on AI—you’ll forget what you learn that way. Google, Stack Overflow, documentation—they'll stick in your brain better. Watch some tutorials to get a solid foundation. And then... start coding.

My App Issues (The Rollercoaster)

Now, let me be honest. It wasn’t all sunshine and rainbows.

I initially aimed to finish the app in a week. If you look at my GitHub, it did take me about a week—but, oh boy, it wasn’t easy.

Appwrite Woes

Everything started fine. I created the UI, set up Appwrite as the backend, and things were rolling smoothly. Until... Appwrite refused to add users to my database. I tried everything, but the issues just kept stacking up. So, I decided: forget this, I’m switching to Firebase.

Thankfully, I had separated my UI from my backend. All I had to do was change the backend implementation. Nothing broke in the frontend—lesson learned: keep frontend and backend loosely coupled via a repository file where all the logic meets.

API Struggles & Hive Mastery

Once Firebase was up and running, it was time to fetch notes from my website's API. I used the http package from pub.dev, which worked fine. But for some reason, the body of the notes wasn’t coming through.

To handle offline data, I integrated Hive, which was great, but initially tricky to set up. I created models, commands, and started syncing API data to Hive. The issue? Still no note body! Eventually, after hours of frustration, it turned out the API itself had the problem, not Hive.

Once fixed, data was flowing and saving properly.

UI Layer & Card-Based Madness

Next challenge: UI design. There were multiple subjects, multiple lectures, and I wanted a card-based interface. One card leads to another, leading to lecture notes at the end. I made templates to dynamically pass data—whether it's research notes, lecture notes, etc.—and the experience became seamless.

Search: Fizzy Finder or Bust

Search was another beast. Firebase’s built-in search? Nah, it won’t cut it. I wanted powerful search capabilities, so I turned to Fizzy Finder and built my own search functionality. This was crucial for scaling.

Note-Taking Feature (The Hell Moment)

After deploying V1, I decided to add a note-taking module. The big question: What editor? Markdown, Rich Text, something else? I found Flutter Quill—perfect!

Or so I thought...

I installed it, ran the emulator... and everything broke. Dependency hell. Turns out Flutter Quill v2.9 had conflicts with my Introduction Screen package. I had to pick one. So, Introduction Screen had to go. I rebuilt the entire introduction UI from scratch with custom animations and flows. Painful—but fun.

Once that was sorted, Hive became my best friend again. I created Hive Operations and Note Taking Actions services. I set up controllers, wired everything up, and data was being saved smoothly.

Google Keep-Inspired UI

For displaying notes, I wanted something like Google Keep. I wasn’t sure how to achieve this, so I turned to Google Studio AI—it generated a UI I didn’t love, but hey, it worked.

CRUD’s Biggest Nightmare: Deleting Notes

Deleting notes became my nemesis. I wanted a recycle bin feature. Hive doesn’t support moving content between boxes. So, I had to manually copy content from one Hive box to another, then delete it, and vice versa if restoring. Hive team, if you’re reading: please add move support—it would make life so much easier!

The Sync Layer (The Final Boss 💀)

One thing left: the sync layer.

All notes were stored locally, but users needed backups in the cloud. Easy in theory, painful in practice.

Where should sync happen? How should users know if their data is backed up? At first, I triggered sync on save, update, delete—but it slowed down the app by 2-5 seconds. Not acceptable.

Solution? Sync runs when the app launches. It detects changes and pushes them to Firebase. I added settings to give users control over sync, and made sure sync runs off the main thread so the UI stays smooth. (Shoutout to AI for helping me figure this out—I was lost!)

Wrapping It Up

After all the battles, late nights, and debug sessions, I finally had a polished app. I called it MS Bridge.

Every flow, feature, and issue taught me something valuable. And trust me, whatever app you’re building, you’ll hit similar hurdles. Just stay patient, keep separating concerns, Google like crazy, and enjoy the ride!

Try It Out Yourself

Download App

The app isn’t live on the Google Play Store just yet, but you can still give it a spin!
Simply head over to my website or download it directly using the link below:

👉 Download MSBridge APK

Explore the Codebase

Curious to see how I built this? Check out the entire codebase on GitHub:

👉 MSBridge GitHub Repository

I’d love to hear your thoughts!
Tell me how I coded, what you liked (or didn’t), and how badly I might have messed things up 😄.
Drop your feedback, suggestions, or even a roast in the comment section—I’m all ears! 👇

Final Thoughts

Now, it’s time for some final thoughts. I did this not just because I’m getting a blog post and a future video out of it, but more importantly—because it was fun. Coding for fun is something I’ve missed, and writing down my thoughts, sharing my experiences—that’s something I truly enjoy.

Here’s the thing: don’t be afraid. You’re an engineer. You’re meant to break things, to see how they unfold, to figure out how things can be done. Coding is fun. Find an idea, and start building. It might look like chaos at times—some parts definitely felt like that—but I genuinely enjoyed every bit of it.

So go on, start coding.

Until then, goodbye nerds.

Check out the original article at rafay99.com for the full story!