Trust & pricing

Trust

Wrkr runs infrastructure so you don't have to, but it deliberately holds as little of your stuff as possible. This page is the plain-language version of that boundary: what's yours, what's ours, and what you're still on the hook for.

What's yours, and what Wrkr can reach

That boundary has two halves, and Wrkr is honest about both, what it never takes, and what it can technically reach. Here's the exact line.

We never ask for your keys, and there is no Wrkr vault.

  • Your secrets. API keys, access tokens, and app credentials live in your VM in your .env files or your own secret store. There is no Wrkr secrets vault, and Wrkr never asks you to hand anything over.
  • Your AI account and keys. You sign in to your own coding tool with your own account; your model API keys are yours. Wrkr never proxies your model calls, your prompts and responses go straight from your machine to your provider, not through us, and Wrkr does not resell tokens or hold your provider account.
  • Your code and projects. Your repositories are just files on your machine. Wrkr has no "projects" product that owns or indexes them.
  • Your app's data. Your database and your stored files are yours to read, export, and take with you at any time.

But "on your machine" is not zero-knowledge, here's what that honestly means.

  • Your home directory, including your .env files and the login your coding tool writes to disk, rides the hourly offsite backup, encrypted. Today that backup is encrypted with a key Wrkr holds, which means Wrkr could technically decrypt a backup. It doesn't. But we won't tell you it can't.
  • While your machine is running, its disk and memory live on a host Wrkr operates. No managed-VM product can honestly claim it is blind to a machine it runs, and Wrkr won't pretend otherwise.

The test still holds: if it's something you'd keep private on your own laptop, it stays private on your machine here too, and for anything you want kept even from a backup, use the pattern in Keeping a value truly private.

Keeping a value truly private

If you want a secret that not even a Wrkr backup can read, keep it in an encrypted file inside your VM, for example with age, git-crypt, or a secrets-manager CLI, and decrypt it only at runtime. Then a backup only ever holds ciphertext, and the key that opens it never leaves your control. Reach for this whenever a value is sensitive enough that "Wrkr doesn't decrypt it" isn't a strong enough promise for you.

What Wrkr does manage

So that you don't have to:

  • Your account and sign-in, and your billing.
  • The machine's lifecycle, provisioning, keeping it always-on, and the host underneath it.
  • Backups, the hourly offsite backup of your work (see below).

Isolation

Your machine is yours alone, one machine per person, isolated from every other customer's. Nobody else is on your box, and other customers' machines can't reach into yours. Getting in requires your sign-in.

The native macOS app authenticates through your system browser and stores your session securely in the macOS Keychain, so it can reconnect without re-prompting. The app itself is code-signed and notarized, so your operating system can verify it's the genuine Wrkr app before it runs.

Durability

Your data is protected at the layer where it lives:

  • Your work, your home directory is backed up every hour, encrypted, to offsite storage, automatically. If your machine is rebuilt, your home directory is restored from the latest backup. System-level changes you made outside your home directory, packages installed with apt, cron entries, edits under /etc, are re-imaged from the base machine on a rebuild, not restored from backup.
  • Your app's database, take on-demand snapshots and restore them, or pull a portable dump anytime with wrkr db export.
  • Your app's files, held in durable object storage that survives a machine rebuild.

Where the backup line falls exactly, and what "restore" does, is on Backups & restore.

Hardening on the roadmap

These are planned, not shipped, named here so the posture above is the whole truth, not a highlight reel. No dates.

  • Per-user backup keys, so a single key can't span everyone's backups.
  • An opt-in passphrase mode, you supply a passphrase Wrkr never stores, so your backups are encrypted to something only you hold. The honest tradeoff: lose that passphrase and those backups are unrecoverable, by design.
  • Backup versioning and object-lock, so a backup can't be quietly deleted or overwritten.
  • Failure alerting, so a backup that ever stops running is noticed, not silent.
  • A regularly exercised restore drill, so "your machine comes back" stays a measured routine, not just a promise.

No lock-in

Everything Wrkr gives you is standard underneath, plain Postgres, plain Redis, plain object storage, plain files. You can export your database, download your stored files, and walk away with your data whenever you want. Nothing about Wrkr traps you.

What stays your responsibility

Wrkr secures the substrate; the application is yours to secure like any app you'd ship:

  • Your app's own security, its authentication, authorization, input validation, and how it handles its users' data.
  • Your secrets hygiene, keep keys in the environment, not in your code or your repo, and in an encrypted file if you want them beyond a backup's reach.
  • Your external accounts, your domain registrar, your payment processor, your AI provider, and their credentials.

Where billing stands

Wrkr operates pre-incorporation. The legal entity and full Terms of Service ship before paid sign-ups open, so no payments are collected today. The beta is free and invite-only; $199/month is the launch price, prepaid, when billing opens. Details: Pricing & access.

The formal privacy policy arrives with public signup; until then access is invite-only and the commitments above are the complete story.