Security and privacy

Renart runs locally against files and connections you control. It does not require an account or a hosted Renart control plane. Released builds include optional usage counts with a first-run explanation and a switch that turns them off for every project.

Keep the server local

The web server listens on 127.0.0.1 by default. Keep that default unless you have a trusted access layer: Renart can edit workspace files and execute pipeline and notebook code, and it does not provide remote-user authentication.

Binding to a non-loopback address requires --unsafe-allow-remote and prints a warning. The flag is an acknowledgement of the risk, not an authentication feature.

Treat workspaces as executable input

Materializing a pipeline or running a notebook can execute SQL, Python, and connector logic from the workspace. Inspect and Live request can also execute queries, code, or HTTP requests, even though they do not materialize the destination table. Review an unfamiliar repository and its dependencies before running it. Use warehouse credentials limited to the environments and operations the project needs.

Renart stores local operational state in the workspace’s .renart directory. Keep pipeline source in Git, but do not commit state databases, credentials, or generated runtime files.

Connection credentials

Connection secret values are write-only in the workspace. A replacement is stored in the operating system’s credential store by default, or it can be bound to an existing environment variable for CI and headless machines. An encrypted local vault is also available when the system credential service cannot be used. It uses age’s authenticated passphrase encryption, stores one per-project file in the user’s application configuration directory outside Git, and holds its unlocked state only in the running Renart process. The project-side .renart/secrets.yml file contains provider references and connection-field coordinates, not resolved values, so it can be reviewed in Git.

Renart resolves a credential only for the operation that needs it. It does not return current values to the browser or write them into plans, run records, or deployment snapshots. Existing inline credentials remain supported for compatibility until they are replaced; keep any config containing them private.

The encrypted vault cannot recover a forgotten passphrase. It locks when Renart stops, so it is intended for interactive local or SSH sessions. Unattended schedules need a non-interactive source of trust, such as an environment binding; Renart never silently downgrades to plaintext.

See Manage connection credentials for the UI workflow, source-selection guidance, and terminal commands.

Application usage analytics

Open Settings → General → Usage analytics to see whether collection is active and change Allow usage analytics. This preference belongs to your operating-system user, applies across projects, and stays outside Git. Turning it off does not limit Renart’s features. Environment opt-outs take priority over the switch.

Released builds send usage events to https://telemetry.getrenart.com/v1/events. The first browser session, including an upgrade from the earlier unlinked analytics, shows the current explanation before collecting events; choose Turn off analytics or Got it. A command-line workspace session prints the explanation to standard error before collecting events. To opt out before the first launch, run:

renart telemetry disable

Or start Renart with RENART_TELEMETRY=off. Renart also respects DO_NOT_TRACK=1 and a nonempty TELEMETRY_OPTOUT. Collection is disabled in CI and development builds, apart from explicitly configured local testing.

The payload contains a random ID for each event, the hour, Renart version, operating system and architecture, plus the operation, outcome and coarse count/duration buckets. A random installation ID links events from the same operating-system user configuration across projects and Renart upgrades. It is not a hardware fingerprint or an account identifier. This is pseudonymous usage data: it lets us count reporting installations and installations that successfully run pipelines. It does not tell us how many people use Renart. Offline use, opt-outs, older releases and failed deliveries are missing from these counts. Events do not include code, query results, file paths, project or connection names, credentials, prompts or raw errors.

Choose Inspect example payload, or run renart telemetry sample, to see a synthetic example without sending it. Events are held in a small memory queue; failed sends are dropped without retrying or writing events to disk. Turning analytics off discards queued events. A request already received cannot be recalled. Other Renart processes check the shared preference before their next record or send. Reset installation ID, or renart telemetry reset, discards the local ID and queued events. A subsequent event uses a new random ID. Resetting or removing the user configuration may count as another installation; copying the configuration to another machine shares its identity. Existing opt-outs stay off when upgrading.

The collector stores daily aggregate counts and temporary event IDs, without raw event payloads or a link between an event ID and its aggregate row. Event IDs expire after seven days. For distinct counts, it stores a hash of the installation ID with its UTC activity day, reported Renart version and whether a pipeline succeeded, without platform or project details. These installation-level records expire 28 days after receipt. Startup and hourly cleanup remove expired records. Authenticated exports contain aggregate counts and estimates, never IDs, individual hashes or sketch bytes. For longer periods, the collector retains compact HyperLogLog sketches: aggregate counters that estimate distinct installations without retaining a list of IDs or hashes. These sketches and aggregate counts have no automatic expiry; estimates are labelled separately from exact counts. “Newly observed” means absent from the retained 28-day history; it is not a count of lifetime first installs. Renart-operated host logs use a 28-day retention policy; the collector does not log request bodies, addresses, user agents or credentials.

The endpoint runs on a Netcup server behind Cloudflare. Network providers can see request addresses and other connection information. Cloudflare’s internal processing follows its privacy policy; Renart’s host-log limit does not establish a limit for Cloudflare’s internal records. Renart’s usage setting does not control network requests made by code you run or services you connect to.

Collector failures do not change query or pipeline results. Events are sent in the background, with bounded requests and no retry queue. The final network send during shutdown is limited to two seconds.

Website analytics

The documentation site’s static build contains no tracker. On getrenart.com, the self-hosted Umami tracker is loaded only after a visitor explicitly allows optional analytics. Declining does not limit the site, and the choice can be changed through Privacy settings in the footer. Query strings and URL fragments are not collected, and an enabled browser Do Not Track preference is respected. See the website privacy policy for the processing details. This website setting does not affect a locally running Renart instance.

Report a vulnerability

Do not publish suspected vulnerabilities in an issue. Use GitHub’s private vulnerability reporting with the affected version, impact, and reproduction steps.