Settings and platform
Security and data
Where Dynomatic keeps your data and credentials, what leaves your machine, and what sandboxes the code you run.
Dynomatic is a desktop app that talks straight to AWS. Your items are never uploaded anywhere, and the app itself contacts one server, for updates and for licensing. This page accounts for all of it.
Where your data is stored
Everything the app remembers lives in one SQLite database named dynomatic.db, inside the app data directory for your platform. On macOS that is ~/Library/Application Support/com.ajarsoftware.dynomatic/. The database runs in WAL mode, so you will see dynomatic.db-wal and dynomatic.db-shm beside it.
The database holds your settings, AWS profile definitions, workspaces, saved queries and scripts, table settings, favorites, recents, tab groups, schema configs, command history, environment classifications, the schema registry, and variable environments. Item data from your tables is not stored there. Query and scan results live for the life of the tab, and the schema registry keeps attribute paths, types, and redacted samples rather than whole items.
Every workspace-scoped row references its workspace with a real foreign key, so Remove workspace & data in Settings genuinely deletes that workspace’s saved queries, scripts, table settings, history, favorites, variable environments, and tab groups.
Credentials
Secrets go to the operating system keychain, under the service name com.ajarsoftware.dynomatic. When the keychain is unavailable, the app falls back to an encrypted row in the same SQLite database, encrypted with a machine-bound key.
The keychain holds a managed profile’s AWS secret access key, session token, and inline MFA secret, one blob per profile. It also holds cached SSO tokens and registrations, cached MFA session credentials, your sign-in session token, a trial token, the API keys you save in Settings under AI, and the key that secure(...) template values are encrypted with. None of these cross the IPC boundary into the interface.
Profiles you already have in ~/.aws/config and ~/.aws/credentials are read in place and shown read only. Dynomatic does not copy them into its own storage and points you at the AWS CLI to edit them.
Note: A
secure(...)template value is encrypted at rest with a key that stays in your keychain, so copying an environment to another machine does not carry the plaintext with it.
What leaves your machine
Three destinations, and nothing else. The app’s content security policy restricts network access to AWS and to app.dynomatic.io.
AWS
Every DynamoDB, DynamoDB Streams, S3, STS, EC2, and IAM call goes to AWS with your own credentials, through the region and endpoint the profile configures. A profile with a custom endpoint sends all of that to the endpoint instead, so a local stack such as dynoxide or LocalStack works end to end with nothing reaching real AWS.
app.dynomatic.io
- Update check. Release builds ask the update endpoint for a newer version 5 seconds after launch and then every 4 hours. The request carries the platform, architecture, current version, and bundle type. Downloaded updates are verified against a minisign signature before they install.
- Sign in. Signing in hands off to your browser over a
dynomatic://deep link and exchanges a sealed-box payload back. Registering the device sends a device fingerprint, a device name, the platform and operating system version, the app version, and the device type. The session is re-verified every 24 hours. - Free trial. Starting a trial sends a SHA-256 hash of the machine identifier, the platform, the operating system version, and the app version. The hash is what identifies the device, and the trial is idempotent server side, so restarting it never mints a second one.
- Feedback. Submitting the feedback form sends what you typed along with the feedback type, feature area, any rating, the app version, and the platform. When you are signed in it also carries your user id and email. Nothing is sent unless you submit the form.
AI providers, only when you configure one
Both AI capabilities are Off by default, and while they are off nothing is sent and the features that depend on them stay hidden. When you do configure one, the app tells you what that capability sends and asks for consent per workspace and per provider.
- Completions, used for Data Model enrichment, sends table structure only and never item data.
- Embeddings, used to generate vectors for search, sends the item text you choose to embed and never runs without a confirmation.
Amazon Bedrock runs in your own AWS account with your own credentials. Local (uzu) runs a bundled model on your Mac and Local (localhost) talks to Ollama or LM Studio, so both keep the data on the machine.
No telemetry
There is no third-party crash reporting and no analytics. Rust tracing output and frontend error reports are written to logs/main.log in the same app data directory and stay there. Credential-shaped tokens, meaning AWS keys, JWTs, and STS ARNs, are redacted before anything is written.
What sandboxes the code you run
Nothing you write or import executes with free run of the machine.
- TypeScript scripts and schema extraction run inside QuickJS.
- Python scripts run inside a feature-stripped RustPython virtual machine.
- In both, the AWS bridge the app provides is the only way out. There is no filesystem or network access of the interpreter’s own.
- Shell execution is allowlisted to exactly three bundled sidecars, the esbuild bundler, the Dynoxide local database, and, on macOS only, the uzu local inference server.
Cost safety
Every long operation can be cancelled, including scans, queries, schema extraction, scripts, exports, and stream drains. Background schema capture is guarded by item and read-capacity budgets that are checked on every page, runs only while the window is focused, and never runs on more than two tables at once. A scan-based export streams to disk rather than into memory. Operations that will cost real money carry an explicit warning before they start.
Sample mode
In Sample mode, all DynamoDB traffic stays on loopback to a local sidecar. The update check and the licensing tick still run. Exiting sample mode deletes the sidecar’s database file outright, so anything you created inside the session goes with it.
Last updated on