DEV Community: phlx0

Cloud sync is a feature you’re paying for with your privacy

phlx0 — Sat, 18 Apr 2026 12:23:28 +0000

Open a new app. Create an account. Verify your email. Choose a plan. Grant permissions. Now you can take notes.

This is the default in 2026. And most developers just accept it.

I've been building local-first terminal tools for a while now, and the more I do it, the more convinced I am that the industry defaulted to cloud sync not because it's better for users, but because it's better for retention metrics and business models. The user pays with their data, their privacy, and their dependency.

This post is a case for the other way.

What "offline-first" actually means

Offline-first doesn't mean "works without internet sometimes." It means the local copy is the source of truth. The network, if it exists at all, is secondary. Your data lives on your machine, in a format you can read, in a location you control.

For developer tools specifically, this means:

No account required to use the tool
Data stored in a documented, open format (plaintext, SQLite, JSON, Markdown)
Full functionality without a connection
Sync is opt-in and user-controlled, not baked into the product

The performance argument

Local I/O is fast. Not "pretty fast" — orders of magnitude faster than a network round trip.

A SQLite query on a local database completes in microseconds. The same read from a cloud API takes 50-300ms at minimum, plus serialization, TLS handshake overhead, and whatever latency your connection adds that day. If you're on a train, in a coffee shop with bad wifi, or just in a part of your office with poor signal, that 300ms becomes 2 seconds or a spinner that never resolves.

For tools you use dozens of times a day — snippet managers, note tools, task lists, config stores — that latency compounds. Local tools just feel instant because they are.

The reliability argument

Cloud services go down. Not often, but they do. And when your note-taking app, your snippet manager, or your task tracker is behind an API, their outage is your outage.

More importantly: cloud services get acquired, pivoted, or shut down. Evernote nearly collapsed. Notion has had serious outages. Wunderlist was killed by Microsoft. Any tool that stores your data remotely is making a bet that the company behind it will exist and be well-run indefinitely. That's a bad bet to make with data you depend on.

A SQLite file on your machine doesn't have a status page. It doesn't have planned maintenance windows. It doesn't send you emails about pricing changes.

The privacy argument

This one is simple. Data you don't send to a server can't be leaked from a server, subpoenaed from a server, sold by a server, or used to train a model by a server.

Developers in particular often store sensitive things in their tools — API keys in notes, internal hostnames in snippets, proprietary code in editors. Routing that through a third-party cloud is a risk that often goes unexamined because the convenience is high and the breach probability feels low. Until it isn't.

Local-first means the attack surface is your machine. That's a problem you already have and already manage.

The portability argument

Here's where it gets interesting. People assume cloud sync means better portability. In practice it often means the opposite.

Cloud tools lock your data in proprietary formats behind APIs that can change or disappear. Try exporting your entire Notion workspace as something a script can parse. Try getting your Roam graph in a format that another tool understands. "Export" buttons are often second-class features built to satisfy regulators, not to actually be useful.

Local-first tools that use open formats — Markdown files, SQLite databases, JSON — are natively portable. Every editor can open a Markdown file. Every language has a SQLite driver. You can grep your data, script against it, version it, diff it, and move it without asking anyone's permission.

Git is all the sync you need

The most common objection to local-first is sync. "What about my other machines? What about my phone?"

For developer tools, git solves this completely and it's already installed everywhere you work.

If your tool stores data as flat files — Markdown, JSON, TOML — you track that directory in a git repo, push to a private remote (GitHub, Gitea, a VPS, anywhere), and pull on other machines. You get:

Full history and diffs of every change
Conflict resolution you already know how to do
Works on any machine with git installed
Works offline; syncs when you're back online
No third-party service in the middle

This is exactly the architecture snip v0.7.0 moved to — snippets as individual Markdown files with frontmatter, tracked in git, with a SQLite index rebuilt from files on startup. The index is git-ignored because it's derived data. The files are the truth.

The same pattern works for dotfiles, notes, task lists, configs, and anything else a developer touches daily.

What local-first costs

I want to be honest about the tradeoffs. Local-first is not free.

No automatic sync. You have to set up git, remember to push, and handle conflicts yourself. For non-developers this is a real barrier. For developers it's an afternoon of setup.

No real-time collaboration. If you need multiple people editing the same document simultaneously, you need a server. Google Docs exists for a reason.

No mobile without extra work. Mobile apps can't easily read from your local filesystem. Working Copy on iOS and similar tools close this gap partially, but it's not seamless.

You're responsible for backups. The cloud provider was implicitly handling this. Now you're not.

For developer tools specifically, most of these tradeoffs are acceptable. You're usually working alone or in async collaboration, you already understand git, and you have backup infrastructure.

A checklist for building local-first tools

If you're building a developer tool and want to get this right:

Store data in an open, documented format (Markdown, SQLite, JSON, TOML)
Default storage path under ~/.config/<tool>/ or ~/.local/share/<tool>/
Expose a --data-dir or equivalent flag so users can point it at a git-tracked directory
Auto-create a .gitignore that excludes derived files (indexes, caches, lock files)
Provide export and import commands so data can move in and out freely
Never require a network connection for core functionality
Document the storage format so users can script against it without reading your source

The tools I trust most are the ones that store my data in a folder I can see, in a format I can read, that I can back up with cp if everything else fails.

That's a low bar. More tools should clear it.

Source: https://github.com/phlx0

I built a terminal screensaver in Go — constellations, rain, braille waves, and full shell integration

phlx0 — Sat, 18 Apr 2026 12:10:49 +0000

Every OS has a screensaver. The terminal had nothing.

So I built drift — a terminal screensaver written in Go that activates automatically when your shell goes idle and disappears the moment you press any key.

https://github.com/phlx0/drift

How it works

drift is built on tcell and renders directly to the terminal at a configurable frame rate (default 30fps). Each scene is its own self-contained animation loop that fills the full terminal dimensions and reacts to resize events.

The shell integration is the core feature. When you source the init snippet, your shell installs a hook that measures inactivity time. After the configured timeout (default 120 seconds), drift launches in place. Press any key and you're back at your prompt — no intermediate screens, no delay.

# Zsh
export DRIFT_TIMEOUT=120
eval "$(drift shell-init zsh)"

# Bash
eval "$(drift shell-init bash)"

# Fish
drift shell-init fish | source

Scenes

drift ships four animations that cycle automatically or can be locked with --scene:

waveform — braille Unicode sine waves rendered in layers that breathe and shift phase over time. Three overlapping wave layers create a depth effect that's surprisingly hypnotic.

constellation — stars drift slowly across the terminal and draw edges between neighbors within a configurable connection radius. Star count, twinkle, and max connections per node are all tunable.

rain — katakana characters fall in columns, matrix-style. The charset, density, and fall speed are configurable.

particles — a flow field of glyphs with configurable gravity, friction, and count. Each particle follows a noise-driven vector field.

Scenes cycle on a configurable interval (--duration, default 60s) with shuffle support.

Themes

Seven built-in themes matched to popular terminal colorschemes:

cosmic · nord · dracula · catppuccin · gruvbox · forest · mono

drift list themes    # preview all themes with color swatches

Configuration

All settings live in ~/.config/drift/config.toml. Running drift config --init writes the default file so you have something to edit from.

[engine]
fps           = 30
cycle_seconds = 60
scenes        = "all"
theme         = "cosmic"
shuffle       = true

[scene.constellation]
star_count      = 80
connect_radius  = 0.18
twinkle         = true
max_connections = 4

[scene.rain]
charset = "ｱｲｳｴｵｶｷｸｹｺｻｼｽｾｿﾀﾁﾂﾃﾄﾅﾆﾇﾈﾉ0123456789"
density = 0.4
speed   = 1.0

[scene.particles]
count    = 120
gravity  = 0.0
friction = 0.98

[scene.waveform]
layers    = 3
amplitude = 0.70
speed     = 1.0

Install

No Go required if you just want the binary:

# macOS Apple Silicon
curl -L https://github.com/phlx0/drift/releases/latest/download/drift_darwin_arm64.tar.gz | tar xz
sudo mv drift /usr/local/bin/

# Or via go install
go install github.com/phlx0/drift@latest

Pre-built binaries for macOS (arm64/amd64) and Linux (amd64/arm64) on the releases page. No CGO, no C compiler needed.

Why Go?

I normally reach for Python for terminal tools (I also built snip in Python + Textual). For drift I wanted a single static binary with no runtime dependency, sub-millisecond render loops, and direct terminal control without a framework abstracting the raw bytes. Go + tcell was the right fit.

Feedback welcome, especially if you have ideas for new scenes or themes.

Source: https://github.com/phlx0/drift

I built a terminal snippet manager that stores snippets as Markdown files you can git-track

phlx0 — Sat, 18 Apr 2026 11:35:19 +0000

You write a clever one-liner. You close the terminal. Three weeks later you're Googling the same thing again.

That loop is what made me build snip a local, offline TUI snippet manager that lives entirely in your terminal. No browser, no account, no cloud dependency.

https://github.com/phlx0/snip

How it works

snip is built on Python + Textual. The UI gives you a searchable list on the left, a syntax-highlighted preview on the right, and a modal form for creating or editing snippets.

Storage went through a significant architecture change in v0.7.0. Snippets are now stored as individual Markdown files with YAML frontmatter in ~/.config/snip/snippets/. A SQLite index (snip.db) sits alongside and is rebuilt from those files on startup it exists purely for fast querying and is excluded from git via an auto-created .gitignore.

This means your snippets directory is a plain folder of .md files you can track with git, push to a private repo, and sync across machines without any special tooling.

~/.config/snip/
  snippets/
    a1b2c3d4e5f6.md   # each snippet is its own file
    ...
  snip.db             # git-ignored index, rebuilt on startup
  config.json         # theme preference
  .gitignore

CLI first, TUI second

The TUI is the main interface, but snip is fully scriptable from the command line:

snip                          # open the TUI
snip "docker run"             # non-interactive lookup, prints + copies to clipboard
snip --exec "deploy script"   # run a snippet directly as a shell command
snip --list | fzf | xargs snip  # fzf integration
snip --add ./script.sh        # save a file as a snippet, language auto-detected
snip --export > backup.json   # dump all snippets to JSON
snip --import snippets.json   # bulk import
snip --from-history           # pick from shell history and save as snippet
snip --json "query"           # output full metadata as JSON for scripting
snip init zsh                 # print shell completion script

Theme system

As of v0.6.0, all UI colors are driven by a Theme dataclass and snip.tcss uses CSS variables throughout. Built-in themes are tokyo-night (default) and dracula.

Custom themes are plain JSON files stored in ~/.config/snip/themes/ shareable as Gists or committed to dotfiles. Syntax highlighting colors (via Pygments) and all Rich inline markup adapt to the active theme.

snip theme list
snip theme set dracula
snip theme import ~/my-theme.json
snip --theme dracula   # one-session override

Install

# One-liner (Linux / macOS)

curl -fsSL https://raw.githubusercontent.com/phlx0/snip/main/install.sh | bash

The installer creates an isolated virtualenv at ~/.local/share/snip, drops a launcher at ~/.local/bin/snip, and patches your shell config if needed.

What's next

I'm thinking about import/export compatibility with other snippet tools (Raycast, VS Code snippets) and potentially a watch mode that syncs changes from the filesystem back into the index in real time.

Feedback welcome — especially if you use a snippet manager already and have opinions on what's missing.

Source: https://github.com/phlx0/snip