Atlas Compass
✦ Under the hood ✦

How Atlas Compass is built

One app for finances, tasks, calendar, habits, notes, goals, study, training and more — built by one person, engineered so your data never leaves your own devices, and tested like a product.

See Atlas Compass Try the live demo

The demo runs Atlas Compass on a public server with sample data — no sign-up, reset daily.

2platforms: Windows and Android
13modules in one app
300+automated tests
240database migrations
5CI jobs on every push
Region I · The map

Where everything lives

The app isn't a website: its server runs on the buyer's own computer or phone. The only thing on our side is the store — and it never sees anyone's data.

The buyer's devices hold the server and the encrypted data; they reach each other directly or through end-to-end encrypted relays; the internet only gives them public data; the store only sells and emails license keys. YOUR DEVICES — your data lives only here Computer Electron app server (FastAPI) encrypted vaults SQLCipher Phone Capacitor app can host the server offline cache + queue locked with a PIN Atlas Connect direct, encrypted end to end · see how below THE INTERNET — public data only Exchange rates · map tiles · weather catalogs with your own keys · update check THE STORE — Cloudflare Paddle · Mercado Pago → signed license key → email downloads for key holders · orders never any user data key

Self-hosted, for anyone

Python's server, packed into one program with PyInstaller, starts with the desktop app — or runs inside the Android app itself (Chaquopy), so a phone alone can host everything.

One web app, two shells

A single React + Vite front end, packaged as Electron on Windows and Capacitor on Android, with narrow-screen layouts of its own for the phone.

Live between devices

A sync socket tells every signed-in device what changed, so the phone and the computer update at once without polling.

Region I · The roads

How your devices connect

"No cloud" doesn't mean the phone and the computer can't talk: they do, directly and encrypted end to end. Atlas tries each way in order and switches by itself when one stops working.

Three ways a paired phone reaches the computer: directly on the home network; over the internet after finding each other through public meeting points that only see sealed messages; or through the user's own relay when no direct path exists. Every way is a WebRTC channel encrypted end to end. 1 · AT HOME — the same network Phone paired by QR Computer server (FastAPI) WebRTC data channel · DTLS · home addresses first depends on nothing 2 · ANYWHERE — over the internet Phone away from home Computer at home Public meeting points open relays · only sealed messages sealed offer sealed answer then straight to each other · DTLS bound to the paired keys 3 · STRICT NETWORKS — your own relay Phone Your relay (TURN) optional · yours · can't read Computer

Paired once, by camera

The computer shows a QR with its public keys and a one-time secret (valid five minutes, used once). The phone scans it, both prove they hold it and swap their long-term keys. The secret never crosses the network.

A bridge, so the app doesn't care

On each device the app talks to a small bridge on 127.0.0.1; the bridge carries every request — data, pictures, music, the live-sync socket — over whichever way works, to the server on the other side.

What outsiders see

Meeting points see only that sealed, signed messages were left under a mailbox name that changes every hour; a relay sees encrypted bytes. Never the contents, never whose devices they are.

Region II · The fortifications

The parts that make it trustworthy

Your data, encrypted at rest

Each account has its own database, encrypted with SQLCipher. Its random key is stored only wrapped twice — by the account's password and by a recovery code — each through PBKDF2-HMAC-SHA256 with 600,000 iterations. Lose both and nobody, including the author, can open it.

Devices that find each other

Each install has an Ed25519 identity and an X25519 key, paired once with a QR code. Away from home, the phone leaves its signed offer on public Nostr relays: sealed to the computer's key (ephemeral X25519 + HKDF + AES-GCM), under a mailbox tag that rotates hourly, with a throwaway key per message. The relays can't read it, link it, or sit in the middle.

A license that needs no server

A key is a small signed payload: Ed25519 over the buyer's email and order, in base32. The app checks it locally, forever, with no activation server. Updates are announced through a signed feed, so the app only trusts news that really comes from the store.

Works without internet

On the phone, what was seen is cached and every change made offline waits in an ordered queue with its own operation id, so a retry is never applied twice. When two devices changed the same thing, it's merged field by field; only a real clash is shown, with a history to undo it.

The store

Cloudflare Pages Functions on a free plan. Payment webhooks are signature-checked (Paddle's within five minutes; Mercado Pago's payment fetched back from its own API), and fulfilment is idempotent — a retried notification never makes a second key or a second email. Orders in D1, installers in R2 behind the key, a key shown on the thank-you page so it never depends on email.

One codebase, four products

The author's own full app, Atlas Compass (what's sold), the public demo and a TV app all come from the same repository, chosen by build flags. Each edition closes on the server what it doesn't include (not just hides it), and tests keep every edition honest.

Region III · The logbook

Design decisions

The choices behind how it works, and why.

Why the server runs on your device, not in a cloud

A personal app holds finances, health, notes and contacts. Keeping the server on the buyer's own computer or phone means there is no central database to breach, no account to lose, and nothing that stops working if a company does. The cost — no automatic cloud — is covered by device-to-device sync and backups the user controls.

Why each account has its own encrypted database

Instead of one database with rows per user, every account gets its own SQLCipher file and its own key. One person's password can never open another's data, an account can be moved, exported or deleted as a single file, and a damaged file affects only that account.

Why the license is checked offline

An activation server would make a local, private app depend on someone else being online. A signed key verified with an embedded public key works forever, without a connection, and can't be forged — so the app keeps working exactly the same no matter what happens to the store.

Why every offline change carries its own id

A phone that was offline replays its queue when it reconnects, and a request can be retried after a dropped connection. Each change carries an operation id the server remembers, so it's applied exactly once; and two devices editing the same item are merged field by field, so only a real clash needs the user.

Why a purchase never depends on email

Payment providers retry their notifications, and email can be late or land in spam. Fulfilment is idempotent — one key per order, however many times it's notified — and the thank-you page shows the key itself as soon as the payment is confirmed, with the email as a copy.

Why one codebase builds every edition

The full app, Atlas Compass and the public demo share one repository, chosen by build flags, so a fix reaches all of them at once. What an edition leaves out is closed on the server, not just hidden in the interface, and the test suite checks every edition separately.

Region IV · The shipyard

The pipeline

Every push to main runs on clean GitHub-hosted machines. Nothing reaches the public demo unless every check passes.

CI/CD pipeline: a push runs four checks in parallel; when all pass the demo is deployed. git push main / PR Front end + store build · size budget · store tests Server + unit tests one migration head · 300+ tests End-to-end Playwright · real server + browser Demo image Docker · build · run · smoke test Deploy demo only if all green Render + UptimeRobot

Continuous integration

The web app builds on Linux (which catches file-name case bugs Windows forgives) and stays within an 800 KB startup budget; the server installs from scratch, its migrations form a single line and 300+ unit tests pass — the license, the editions, sync, currencies, backups; Playwright drives the real server in a browser; the store's payment flow is tested with the providers faked.

Continuous delivery

Only a green main redeploys the public demo, which runs Atlas Compass itself. A version tag (v*) builds the Windows installer and the Android APK and publishes them with that version's section of the changelog; the store and its database deploy with Wrangler.

Infrastructure as code

The demo is a two-stage Docker image run as an unprivileged user with a health check, described in render.yaml; the store's bindings (D1, R2, KV) live in wrangler.toml and its schema in schema.sql. Everything can be recreated from the repository.

Region V · The cargo

Stack

Destination

Made by

Nicolas Lozano · LinkedIn · [email protected]

See Atlas Compass Try the demo