+1(613)852-9202 [email protected]
Select Page

ScaleTag

A small local app. Security you can follow.

Ask a neighbourhood question, publish a small task or find what is happening nearby. ScaleTag combines polls, public task replies and a location-aware list and map in an installable web app.

From a local idea to a shared post
  1. Ask or offerCreate a poll or a task with a reward.
  2. Add a placeConsent to an approximate map position.
  3. Share & respondOpen a link, scan a QR code, vote or reply.
  4. Keep it currentVoting closes in 7 days. Posts expire in 30.
For example: choose a neighbourhood meeting time or find help with a small local job. No account or app-store download is required.

Task replies publish the contact details people choose to share. Arrangements and payments happen directly between people; ScaleTag does not process payments. Browser cookies support participation limits, not verified identities.

Open ScaleTagView source on GitHub

One controlled way in.

Cloudflare Tunnel reaches a local Nginx ingress. The origin needs no public web ports; firewall rules restrict inbound access and server administration uses SSH keys.

A request crosses several checks
  1. BrowserHTTPS request
  2. CloudflareTunnel to the origin
  3. Local NginxPreferred app1; app2 is backup
  4. ApplicationOrigin, input, size and rate checks
  5. SQLiteTransactional access to encrypted data
A tunnel restricts the entry path. Application checks still validate the request.

Readable in use. Encrypted on disk.

SQLCipher AES encryption covers the SQLite pages, including schema and post documents. Two application instances share the same database; transactions protect counts and deduplication.

Writing and reading a record
  1. Accepted writeValidated post, vote or reply
  2. TransactionCheck and update together
  3. SQLite cipherEncrypt database pages
  4. Disk fileEncrypted SQLite storage
  1. Encrypted pagesRead from the disk file
  2. Correct keyOpen and decrypt in memory
  3. ApplicationBuild the permitted response
  4. BrowserReceive public content over HTTPS
A copied database file cannot be opened without the correct key. Missing or incorrect keys fail to open the encrypted store.

The database engine manages page IVs and salts. Non-root containers and private file permissions add access control around the encrypted file.

The key travels with deployment.

A random 256-bit key starts in a GitHub Actions repository secret. It is delivered at runtime, keeping it out of source code and container images.

From GitHub Secret to both instances
  1. GitHub SecretSCALETAG_ENCRYPTION_KEY
  2. Deployment jobPass the key on standard input
  3. Root-owned helperValidate; save a root-only host environment file
  4. Runtime environmentSystemd and Docker provide the same key
    Node app1Node app2
The helper rejects accidental key replacement. A secure recovery copy is essential; changing a Secret alone is not key rotation.
Where is the key visible?

The host environment file is root-only. The running containers receive the key as an environment variable, so host root and Docker administrators can inspect it. This deliberately simple deployment protects against file-only disclosure, not full server control.

Backups stay encrypted, too.

Daily exports use AES-256-GCM with a fresh 12-byte IV and an authentication tag. The backup directory is root-only and is not mounted into the app containers.

Daily backup · 03:00 Toronto time
  1. Read transactionExport a consistent database view
  2. AES-256-GCMFresh IV + authentication tag
  3. VerifyAuthenticate and decrypt the export
  4. Publish archiveAtomic publication; 90-day retention
Existing local plaintext archives are encrypted and verified before their original files are removed.
Recovery · verify before replacing live data
  1. Encrypted archiveSupply the original key
  2. AuthenticateReject wrong keys or altered ciphertext
  3. New staging databaseRestore in a transaction; check integrity
  4. Controlled swapValidate offline, then stop both instances to replace active storage
The restore tool refuses an existing target path. Restoring records does not extend their original public expiry.

Tested with real data: the encryption migration preserved all four existing records. A real encrypted backup restored the same four records into an isolated database and passed integrity checks. Opening the database without a key was rejected.

Test first. Replace one instance at a time.

Routine releases use readiness checks and Nginx failover. The initial encryption migration pauses both writers to convert the database safely.

Routine rolling release
  1. CI passesBackend, browser, backup, container and HA tests
  2. Update app2Verify readiness
  3. Route to app2Take app1 offline
  4. Update app1Verify readiness
  5. Fail backConfirm traffic returns to app1
Only the tested main-branch commit is deployed. Old images with an unencrypted driver cannot open the encrypted database.

Know the protection boundary.

Files obtained without the key

The database and backups stay encrypted. Wrong keys cannot open the database; backup authentication detects altered ciphertext.

Control of the running server

Privileged administrators can reach the runtime key and plaintext in memory. Public posts and consented reply contacts remain public.

Active posts expire after 30 days; backups have their own 90-day window. Browser cookies are not identities. File deletion is not forensic erasure, and provider snapshots require a separate policy.