Legal and privacy

Privacy Policy

Version: 1.9.9 · Effective: 31 July 2026 · Last updated: 25 October 2026 (Stand: 2026-10-25)

1. Controller

Gian-Luca Luongo, Dorfstrasse 77, 5430 Wettingen, Switzerland info@zerolog.ch

The controller is a natural person, not a company. There is no Data Protection Officer; the controller answers data protection requests personally at the address above.

EU/EEA and representation. Where ZeroLog offers services to people in the EU/EEA or monitors their behaviour there, the GDPR applies under Art. 3(2). Mere access to a Swiss website does not by itself settle that question. No representative under Art. 27 GDPR has been appointed. The operator does not claim the Art. 27(2) exemption: regular operation of a service is not shown to be occasional, and the exemption's other conditions have not been established. If Art. 3(2) applies and no exemption applies, the duty to appoint a representative remains unmet. The Swiss contact address above does not replace an EU representative or limit your rights.

2. About the name

ZeroLog supports accounts without a real name, phone number or optional email address. The separate waitlist and preview application do require contact data. Account sign-in and security processing are described below; the name is not a promise that no IP address or other personal data can ever be stored in a log, message, attachment or other user-supplied content.

IP addresses are processed for transport, security and abuse protection. Some counters are held only in memory; security logs can retain addresses for weeks (§3.4, §8). ZeroLog does not add a source IP field to your ordinary account or chat history, but content supplied by users or tools can itself contain an address. Accounts with the administrator role are the exception: their full address is kept in the operations log for up to 30 days (§3.4.1). This does not apply to customer accounts.

One caveat belongs up front: paying identifies you. Registration collects no name, but card payments can disclose billing and identity data to Stripe (subscriptions) or MoonPay Commerce / Helio (manual credit purchases). The latter can require identity verification and settle USDC to the operator's custodial Bybit wallet. Payment providers and the operator can link payment records to an account. Payment is not anonymous; an unpaid account is not necessarily untraceable either.

It does not mean nothing is written down. Ordinary chats are stored so your history is there when you return. Usage is recorded so you can be billed accurately. Security events are logged so the service can defend itself. This policy states plainly what exists.

If you want content the operator genuinely cannot read, use anonymous chats (§6).

3. What is processed

3.1 Account

• Username, registration timestamp, permission flags, and the link to your sign-in identity.
• Sign-in runs through the operator's own identity service (Keycloak at auth.zerolog.ch, on the operator's servers in Switzerland). It holds your password and any second factor you set up and checks them when you sign in. ZeroLog itself stores no password. Sign-in does not run through Google or any other outside provider.
• An email address is optional and empty by default. You may add one; you may remove it again. Without one there is no password reset and no way for us to notify you — that is the trade, and leaving it blank stays a fully supported choice.
• No phone number, no real name. There is no field for either.

3.2 Chats, messages and files

• Chat titles, messages, attachments, generated images, and files inside your containers, stored in a SQLite database and on disk on the server in Switzerland.
• Prompts you send are transmitted to Featherless, the inference provider for customer accounts (§5), to produce a reply. This is the core of the service and cannot be switched off while using a model. Your own connected accounts (Claude Code, Codex) are the exception, and they are yours, not ours (§5).
• Preview links. When an app or site running in your container is shown in the preview panel, it is reachable through a web address that carries its own permission (a capability token); the link itself is the credential. Anyone who has the link can open the preview without signing in to ZeroLog until the link expires or is revoked, and only while the container exists and is running. Treat such a link like a password, and do not post it somewhere public if the preview shows something private.
• Preview links: expiry. Every link has a stored expiry date, 7 days by default. When you create a shareable link yourself, you choose 1 hour, 24 hours, 7 days or 30 days; a longer period is not possible. Links issued before expiry dates were introduced received 7 days from the day that change went live and stop working after that.
• Preview links: ending a link early. In the preview panel you can revoke a single link or all links of a container. A link also stops working when the chat it belongs to is deleted, when the container is deleted or recreated, or when the account is disabled. An expired or revoked link then shows a page saying so.
• Preview links: connections that are already open. Expiry and revocation are checked on every page or file request and whenever a live connection (WebSocket) is opened. From that point the link stops working for new requests and new connections. A live connection that was opened before is not cut off; it continues until it is closed.
• Preview links: what is stored. For each link: the container, the account, the port, a random value, whether the link was created automatically or by you, and the times of creation, expiry and, where applicable, revocation. The link address itself is not stored; the server recomputes it from these values with a secret key. A row more than 30 days past its expiry or revocation is deleted the next time a link is created for the same container; otherwise the rows stay until the account is deleted, and they are part of a data access request.
• Preview links: protection against guessing. Requests with an invalid link are counted per IP address so that links cannot be guessed by trying: after 60 invalid attempts within one hour, that address receives no preview through any link for the rest of the hour. The count is held only in the server's memory, not in the database or in a log. An attempt counts for one hour; expired counts are removed at the next cleanup, which runs with later preview requests, and all counts are lost on a restart.

3.2.1 Separate image engine

The optional Bilder / Images feature sends your image prompt and selected dimensions to Infomaniak Network SA (Switzerland) to create one image with Flux schnell. Generating from the form is an explicit request; image tools for AI chats are off until you enable their separate switch. Images are charged from your ZeroLog balance, which you can fund with MoonPay.

The form prompt stays in memory during processing. The image job database stores an owner-linked request identifier, a keyed check value for duplicate detection, status, dimensions, fixed price, timestamps and expiry, without the prompt or the provider's revised prompt. Results and request metadata are stored privately on the ZeroLog server for 30 days, with automatic cleanup. Deleting a result removes its actual file sooner; the duplicate-detection record remains until expiry. Deleting the account removes the request records; the cleanup also removes orphaned files. Financial usage and reservation records follow the existing accounting retention. Backups have their own retention (§8) and are not described as immediately erased by a gallery deletion.

AI tool arguments can contain the prompt in the existing chat history; the selected chat's retention still applies. A Coding Agent can save an owned result in its own container and use a vision-capable model to inspect it; chat processing can then send the image to the selected model provider. Local file copies and shell histories follow the workplace's retention, independently of the gallery. Native provider login credentials and the Infomaniak API key are not transferred between these services. Infomaniak describes Swiss processing and no query retention; this has not been independently verified and is not a platform-wide Zero Data Retention guarantee.

Previously stored images remain deleted. OpenRouter image generation remains disabled. The Design Engine uses HTML, inline SVG and CSS and does not generate or reuse images.

3.2.2 Appearance settings

If you change the look of ZeroLog under Settings > Appearance while signed in, the server stores your choices with your account: preset, accent colour, typeface and text size, background, motion and layout options, keyboard shortcuts and similar values. Designs you save yourself are stored the same way. These values are colours, numbers and fixed options; apart from a design name, the server rejects free text.

You can upload your own background image (PNG, JPEG or WebP, up to 3 MB). The server decodes the file and stores a newly encoded WebP copy with at most 2560 pixels on its longest side; metadata such as location and camera data is not carried over, and the uploaded original is not kept. Each account holds at most one background image: uploading a new one deletes the previous file. The image is stored on the server in Switzerland, delivered only to your signed-in account and not passed to any other recipient. Like all traffic it travels through Cloudflare (§5).

On the Max plan you can submit a saved design to the public design gallery. Submitting stores a copy of the design's current values and name; later edits reach the gallery only if you submit it again. Before a design appears, an account with moderation rights reviews it and sees which account submitted it. Once approved, the design and its name are visible to all signed-in accounts, without your username or any other indication of who made it, and other accounts can save a copy, which then belongs to their account. When another account reports a design, the server stores the reporting account, a reason from a fixed list and the time; to count copies it stores which accounts saved one, once per account. Reports are deleted when a moderator approves the design again or you resubmit it. The gallery entry with its reports and copy records is deleted when you withdraw it, delete the design or delete your account; copies others have already saved stay in their accounts.

You can remove the image under Settings > Appearance at any time; resetting your appearance settings removes it too. Otherwise it is deleted when you upload a new one or delete your account. Without an account, appearance settings stay in your browser's local storage and are not sent to the server.

3.2.3 Design Engine artifacts

Where the Design Engine is switched on for your account, ZeroLog treats an .html, .htm, .svg, .jsx or .tsx file that an AI model writes into your chat's container as a design artifact and shows it in a preview panel next to the chat. That covers files written with the AI's file tools, files Claude Code or Codex change during a turn, and code blocks the AI saves under a /work/ path. The /design command loads the same tools into an ordinary chat turn. The Design Engine is not available in anonymous chats.

• No additional recipient. The model work runs on the model of your chat or on a model set for the Design Engine; for a customer account both are Featherless models (§5). When the Design Engine scores a rendered design, a screenshot of it goes to that model as part of the prompt. Building a React component downloads fixed open-source packages (React, esbuild, Tailwind) from the public npm registry; that download carries none of your content.
• What is stored: one run per account, chat and file path, and one row per version of that file with its full source and the page rendered from it. This lives in the same database as your other chat data, on the server in Switzerland.
• The stored preview is sealed off. A saved version opens only for your signed-in account. It renders in a sandboxed frame with no access to your cookies, your session or your account, and with no network access of its own: it cannot load fonts, scripts or images from the internet. Viewing it creates no new telemetry.
• The live draft is not sealed off in the same way. While a file is still being written, the panel shows a draft without running its scripts. Images the file references by an internet address can load in that draft, and the site hosting such an image then sees an ordinary request from your browser.
• Retention and deletion. Deleting a chat deletes that chat's design runs and every stored version of their files. Deleting your account deletes all remaining design runs and versions in the same pass that removes your other account-linked data (§8). The file in your container is part of the container and goes when the container is deleted. Backups follow their own retention (§8).

3.2.4 Key proxy for third-party keys

When you store an API key for a third-party service with your account (the key service currently has profiles for Cloudflare, GitHub, Hetzner, Infomaniak, Netlify, OpenAI, Porkbun, Stripe, Tailscale and Vercel), the key is not stored in the main application. It lives in a separate key service on its own virtual machine on the operator's hardware in Switzerland, with its own database, encrypted with a data key of your own (AES-256-GCM) that is in turn wrapped with the service's master key. The main application reaches it only over a mutually authenticated (mTLS) connection. Agents, tools and templates in your chats only ever see a placeholder; the key service swaps it for the real value immediately before the request leaves for the provider, and removes your stored key values from the provider's response before it reaches the agent. Where a provider's profile names the field in which the provider hands back a new secret (a freshly issued token, for example), that secret is caught and stored the same way, and an agent only ever sees a placeholder for it too.

• Passkey first. No key can be stored until you have registered a passkey. For 24 hours after your first passkey is registered (48 hours after a passkey reset), the key service accepts no passkey confirmation, so in that time no key's access can be widened and no payment can be approved; storing a key read-only and locking a key work at once.
• Approvals. A new key starts read-only. An operation the key's rule does not already allow waits a short time (currently up to 60 seconds) for your approval and is refused if none comes. You are notified through the push channels you switched on (§3.7); the notification carries no details of the request. Approving a single ordinary operation once needs no passkey; approving it permanently, widening a rule or approving a payment needs a passkey confirmation. For each approval request the key service stores the provider's host name, the method and the path of the request, and keeps that record until you delete your account.
• Approval log. Every approval, every change to a key or its rule and the other key events are written to an append-only, hash-chained log, so a later edit to an entry would be detectable. There is no fixed retention period. New-format entries lose their account reference and details when you delete your account; legacy entries do not support that removal, as explained below.
• Full access. Full access is off by default for every key. Turning it on needs a passkey confirmation and a warning that names payments, and you do this per key, not as an account-wide default. Outside full access, payment and purchase operations always wait for your approval. Once full access is on for a key, every operation under that key, including payments, runs without asking.
• Your own AI provider key. If you store a key for an AI provider (currently OpenAI) and an agent in your container uses it, the request goes to that provider under your own contract with it, like the own accounts described in §5. That provider's own data handling and retention apply to it, not the Featherless retention commitment described in §5.
• Keys for use outside ZeroLog. You can create a separate key for a site or service you run elsewhere. The key service stores only a checksum of it; it can never carry full access, it expires after at most one year, and you can bind it to one IP address. Requests made with it pass the same abuse protection as other requests (§5, "Security processing"). A site you host elsewhere reads its own code, including anything embedded in it; prefer a key limited to what that site actually needs.
• Instant lock. Locking a key from the panel stops it working everywhere at once.
• Account deletion. Deleting your account first deletes everything the key service holds for it: keys, placeholders, rules, external keys, passkeys, approval requests and your data key. If the key service cannot be reached, the deletion stops and nothing is deleted. Your entries in the approval log are emptied: the account reference and the details are removed, and only a number, a timestamp, the type of event and checksums remain, so the log stays verifiable. Entries written before this emptying was introduced cannot be emptied this way and keep the account reference and their details, including after account deletion, with no fixed deletion period currently implemented for those legacy entries. This is a remaining limitation, not a claim that account deletion removes all personal data from the log. The key service's own backups follow their own retention.
• Containers with their own VPN access bypass the key proxy entirely and cannot use keys stored there. This is enforced technically: such a workspace never receives the key service's certificate or any secret.

3.3 Usage and billing

• Per-request: model used, token counts, cost, timestamp, and which chat it belonged to. This is what your ledger and spend limits are computed from.
• Payment records: Stripe subscription/customer/invoice identifiers and MoonPay Commerce / Helio charge references, amount, currency, status and credit allocation. USDC settlement uses the operator's configured custodial Bybit wallet. Transaction data can be public on the blockchain. ZeroLog does not store card numbers: the payment providers handle card entry and any identity verification in their checkout. Their own retention and legal duties apply.

3.4 Technical and security data

• Session records (a hashed session identifier, creation and expiry time) so you stay logged in. While sign-in logging is switched off (next item), no last-use time is recorded for devices and ZeroLog Code tokens.
• Sign-in events of customer accounts are currently not recorded. The service runs with sign-in logging switched off. For every account without the administrator role, ZeroLog then stores no sign-in events (no time, outcome, browser identification or check value of the source address), writes no lines about sign-ins, second factors, passkeys or account emails to its server logs, and does not record when you last signed in. The list of sign-in events in Settings therefore stays empty, and there is no warning about a sign-in from an unfamiliar place (§3.7). If sign-in logging is switched on again, ZeroLog records for each sign-in the time, the outcome, a shortened browser identification and a one-way check value (HMAC) of the source address, never the address itself, shows these events to you under Settings and deletes them after 90 days. This policy will be updated before that happens. Sign-ins to administrator accounts appear only in the operations log described in §3.4.1.
• Rate-limiting and abuse counters keyed on IP in memory and in short-lived server logs. For customer accounts, IP addresses are not stored in a database as part of the account or its history. Administrator accounts: §3.4.1.
• Server logs (errors, security events such as blocked abuse, container lifecycle). These can contain an IP address transiently and are rotated by the system journal.
• Technical access log. For fault finding, the proxy and the application each write one line per request: time, method, path without parameters and identifiers (the query string is dropped; numbers, tokens, account and file names are replaced by placeholders), status, duration, size in bytes, the serving part of the service and a request ID. It contains no IP address, no browser identification, no cookies, no content and no account, so a line cannot be assigned to a person. The request ID carries no reference to a person; only for administrator accounts can it be linked to the operations log (§3.4.1), which stores the same ID. The log can be read by root only, not by the service itself, and entries are deleted after at most 14 days. Purpose: operational security and fault finding; basis: overriding private interest (Art. 31(1) FADP), for the GDPR legitimate interest (Art. 6(1)(f)). No evaluation per person, no disclosure.
• Container and agent activity: commands run, exit codes, tool calls, needed to show you what an agent did and to investigate abuse.
• Runtime security events: when a process inside a container shows one of a fixed list of suspicious behaviours, a short pseudonymised event without content (§10).

3.4.1 Operations log and session recording for administrator accounts

Since 23 October 2026, ZeroLog keeps a detailed operations log for administrator accounts only, that is accounts with the administrator role: the operator's own and those of persons he has given such an account. Its purpose is to find faults and to trace what an administrator did and what it caused. Customer accounts are not logged here: an entry is written only if every account involved in it has the administrator role, and anything in which a customer account acts is discarded before it is stored. The zero-log setting for customer accounts in §3.4 stays as it is.

• What an entry can contain: account number and username of the administrator; the full IP address; device and browser identification (user agent); method, address and query of each request; request and response content, shortened to 64 KB; inputs and replies of administrator chats; tool calls with arguments and results; container, terminal and worker actions with their output; requests to model providers (model, parameters, status, error text, token counts); durations; error messages with stack traces; and sign-ins to administrator accounts with their outcome. For admin views and actions that concern customers, much less is kept; see the next points but one.
• What is removed first: passwords, session cookies, keys, tokens, one-time codes, recovery codes and vault contents are replaced by a marker before storage. This works by field names and patterns and can miss an unusual form.
• System events without reference to a person (deployment, server state, timers) carry no account and no IP address. In a request made by a customer account they are discarded as well.
• Admin views and actions concerning customers: target ID, status and size only. Since version 1.9.8, every admin view and admin action that can show or change customer data (for example the account list, an account's settings, permissions, credit and refunds, usage and billing figures, payouts, the waiting list and test-access requests, terminal requests, the gallery moderation, outbound destinations and the outbound log of containers, security events, exports of an account, client error reports) is logged without request or response content. Such an entry keeps only: who acted (administrator account, IP address, user agent), method and address without query values, the status code, the duration, the size of request and response in bytes, the IDs of the affected objects (for example account number, container or chat ID), the names of query parameters with only ID and paging values, a fixed error code, and for faults the error type and the code locations of the stack trace without the error message. Log lines and events that other parts of the service write during such an action are reduced in the same way to IDs and codes. This rule applies to every admin address by default; only admin views that serve the operation of the service and never carry customer data (for example service settings, prices, provider balances, network and firewall status, the newsroom, server images) are logged with content.
• What can still point to a customer: the account number or other ID of the affected object, linked to the time and to the administrator who acted. If an administrator types customer data into one of the operational views logged with content (for example into a newsroom post or a setting), it is logged there with that content. Entries written before version 1.9.8 can still contain the full content of such actions until they expire after 30 days at the latest.
• Where and how long: in a separate database on the main server in Switzerland, held in volatile memory (tmpfs), not on disk. It is lost when the server is restarted and is not part of the encrypted backups (§8). Operation entries are deleted after 30 days, the record of access to the log after 90 days; above 256 MB the oldest entries are deleted first. The cleanup runs every ten minutes, starting with the first entry the service writes after it was started. Deleting a customer account does not remove entries early; they expire as described.
• Who sees it: only administrator accounts, in the admin view "Logs". Every view, detail view and export of the log is itself recorded and kept for 90 days. Service tokens can read the log only with their own read-only permission. An exported copy is no longer subject to the periods above; the operator uses exports only to resolve a fault and deletes them afterwards. Nothing is passed to third parties, and the log is not used to assess the performance or behaviour of administrators.
• Session recording of the operator's own account. For the operator's own account (account 1) only, the web interface also records mouse movements, clicks with the short visible text of the clicked element, field inputs, navigation, requests, scrolling and script errors, so that the operator can reconstruct what he did. Password, one-time code, token, key and vault fields, and the vault and key pages as a whole, are masked in the browser before anything is sent; the server redacts a second time. No screenshots and no page contents are recorded. The recorder is loaded only for that account; for every other account it is not loaded and nothing is recorded. On the admin pages (which show customer data), and on any other view marked as showing customer data, the recording keeps only the role and position of the clicked element, its technical selector without visible text, and the ID of the affected object (for example the account number of a row in the account list); element texts, field inputs, query values of addresses, console output and error messages are not recorded there. The browser leaves them out and the server removes them a second time. Outside those pages, clicked texts and inputs are recorded as before; they concern the operator's own use. The files are kept on the main server's disk in Switzerland, readable only by the service and the operator; folders older than 30 days are deleted by a cleanup that runs every six hours while recordings are being made. Another administrator account would be recorded only after being added explicitly, after that person has been informed, and after this policy has been updated.
• Legal basis: overriding private interest in a secure, working service and in traceable administration (Art. 31(1) FADP); for the GDPR, legitimate interest (Art. 6(1)(f)). The session recording concerns the operator himself, at his own request. A customer whose account number appears in an administrator action can request access and object (§9); the operator then searches the log.

3.5 What is deliberately NOT collected

• No advertising or analytics trackers, no tracking pixels, no third-party cookies.
• No profiling, no automated decision-making with legal effect, no sale of data.
• No behavioural advertising of any kind.

3.6 Error and crash reports

The ZeroLog web interface, the ZeroLog Android app and ZeroLog Code report errors and crashes to this server, so that faults can be found and fixed.

• What a report can contain: an error code and a shortened error message; for a crash, a redacted and shortened part of the stack trace; and limited details such as the app version, device and operating system, browser, and page or screen where it happened. A report can also include an approximate time and a coarse estimate of how long the app had been running. These details help identify the fault. Reports are not meant to include account or chat identifiers or chat content. Redaction uses pattern matching and can miss unusual forms, so error text may rarely contain a personal fragment.
• What is not kept: the error store has no field for an account or user identifier, for chat content or for the IP address. Before anything is stored, the server removes email addresses, credentials, identifiers such as UUIDs, home-directory paths that carry a user name, the query part of web addresses and IP addresses from the text. That is pattern matching: it catches the known forms and can miss an unusual one, so in rare cases a message can still hold a personal fragment, for example an email address in an unusual spelling.
• IP address: a report arrives over a normal connection, so your IP address comes with it. The endpoint uses it only in memory, to throttle floods, and does not write it to the error store. Like any request it can appear briefly in the server logs (§3.4) and passes Cloudflare (§5).
• On your device: a report the apps or zerocode could not send, for example because the program crashed, stays on your device until the next successful send and is then deleted.
• On the server: reports of the same kind are merged into one entry per error form, with a counter and the times it first and last occurred. An entry becomes due for deletion when its error form has not occurred for 30 days. The cleanup runs when a new report arrives, at most once an hour, not on a fixed timer; while no reports come in at all, a due entry can stay longer, until the next report. A form that keeps occurring keeps its example message for as long as it keeps occurring. A merged overview of the last 30 days is rebuilt every 10 minutes; a change log of that overview (which forms are new or growing, with their example message) is kept on the same server. Its entries are removed after 30 days by the existing ten-minute overview timer, including when no new reports arrive; if the timer fails, deletion waits for its next successful run. This change-log limit does not change the per-error-form rule above.
• Who sees them: the operator, and an automated check the operator runs, which reads the merged overview and opens repair tasks. That check uses a language model of Anthropic, PBC (USA), so the redacted entries reach Anthropic. They have no field for an account identifier or an IP address. If redaction misses something personal in a message, that fragment reaches Anthropic too. Nothing else is passed on; there is no third-party crash service.
• Legal basis: overriding private interest in a working and secure service (Art. 31(1) FADP); for the GDPR, legitimate interest (Art. 6(1)(f)). You can object (§9).

3.7 Push notifications

Push notifications are off until you switch them on. There are two separate channels.

ZeroLog apps (ntfy). The ZeroLog apps receive notifications through an ntfy server that the operator runs at ntfy.zerolog.ch, on the same server in Switzerland as the rest of the service. That server does not pass notifications on to ntfy.sh, Google (Firebase) or Apple.

• What it notifies about: a reply that finished or failed while you were not watching; a job that finished, is waiting for you or failed; credit running low; a new sign-in to your account from an unfamiliar place (not sent at present, because sign-in events are not recorded, §3.4); and, only if you switch it on, a change to the legal texts. Each kind can be switched on or off in Settings.
• What is stored: one random channel name (a "topic", 128 bits of randomness, not derived from your account) per account, and when it was created. It is created the first time you switch push on and kept until you switch push off, generate a new channel or delete your account. It is part of a data access request and is deleted with the account.
• What a notification says: only fixed, generic texts, for example "Reply ready: the reply in chat #12 is ready", with at most a chat or job number. Never chat content, chat titles, names, amounts or error messages. The number opens nothing without signing in.
• Temporary storage on the ntfy server: sent notifications are kept for 24 hours, so a device that was offline can still fetch them, and are then deleted.
• Who can read them: anyone who knows the channel name can read the notifications sent to it; only the ZeroLog server can send. Keep the name to yourself. You can generate a new channel at any time: the old one then receives nothing new, and what was already sent to it stays retrievable until its 24 hours are up. Or switch push off, which deletes the channel name.
• Connection: your device reaches ntfy.zerolog.ch through Cloudflare (§5), like every other request, so Cloudflare sees your IP address, the channel name and the generic text in transit. The ntfy server uses the IP address in memory to limit requests; it can appear briefly in the server logs (§3.4).

Browser notifications (Web Push). In the web interface you can allow notifications under Settings. This uses the standard Web Push mechanism of your browser: the browser registers with its vendor's push service (Chrome and Edge: Google; Firefox: Mozilla; Safari: Apple; Windows: Microsoft) and hands ZeroLog an address at that service. Your browser chooses the push service, not ZeroLog.

• What is stored: per device, that push address, the two keys the browser supplies for encrypting messages to it, an optional device label, when it was registered and a counter of failed deliveries. It is deleted when you remove the device, when the push service reports that the subscription was revoked, or with the account, and it is part of a data access request.
• What passes the push service: the notification's title and a short text, for example the event, a job's type and number, the reason it paused, or the domain name a domain watch is waiting for. It is encrypted for your browser before it leaves the server, so the push service cannot read it. It does see the push address, the time and size of the message and your device's connection. It keeps an undelivered message for at most one hour. Google, Mozilla, Apple and Microsoft are based in the USA.

Legal basis: notifications are a function of the service that you switch on yourself, so they rest on contract performance (Art. 6(1)(b) GDPR), not on separate consent; you can switch them off at any time. Handing a Web Push message to your browser's push service is directly connected with that contract (Art. 17(1)(b) FADP); its content is encrypted so that the push service cannot read it.

3.8 Waitlist and preview applications

The waitlist stores your email, consent version/time, source label, confirmation and unsubscribe token hashes, state and relevant timestamps. The confirmation email is sent through SMTP2GO. Unconfirmed entries are deleted after seven days; invited entries after 30 days. A confirmed entry awaiting invitation remains until invitation or withdrawal. The unsubscribe route removes the entry. Cleanup runs through the application's cleanup process, not a promise of deletion at the exact second a period ends. IP/email rate-limit counters are separate from the waitlist record.

A preview application additionally collects name, optional company and a description of your use case, consent version/time and delivery status. It is sent to the operator by email and stored on the Swiss application server for up to 365 days before cleanup. A deletion request can be sent to info@zerolog.ch. Email copies and backups have their own retention. These voluntary contact forms are separate from the optional email field of an existing account; they do not create an account or promise admission. Consent covers the requested contact and invitation; you may withdraw it.

4. Why, and on what legal basis

5. Who else sees anything (recipients and sub-processors)

One inference provider for customer accounts. Every model a customer account can pick is served by Featherless (USA). The model picker shows nothing else, and the service refuses a model id from any other provider, whichever way it arrives: the chat, the command line, the Anthropic-compatible API, the site builder, agents, jobs or the browser extension. The same holds for the steps the service runs on its own on your behalf: condensing a long chat, extracting memory candidates, describing an image for a text-only model. They run on Featherless too, or not at all. ZeroLog does not switch a failed customer request to its other provider accounts. An empty balance stops the request. This describes ZeroLog's own routing, not Featherless's internal processing: Featherless lists OpenRouter as a possible fallback subprocessor in its Global DPA. ZeroLog has no per-account control over that internal route.

Using ZeroLog as a customer involves these third parties:

Retention at Featherless — provider commitment. In its written confirmation to ZeroLog dated 28 September 2026, Featherless states that prompts and completions sent through its Developer API are processed in real time and are not stored at any point. It retains only metadata for abuse monitoring and error handling, without prompt or completion content. It does not use those contents for training, fine-tuning or evaluation. Its current Privacy and Logging documentation also describes real-time API processing without storing prompts or completions. The Global DPA's Annex III lists 13 subprocessors in the version discussed in the September correspondence, not just Cloudflare and AWS: examples include Skylab Services (Singapore), Hydra Host, TensorWave and OpenRouter (fallback), as well as Elasticsearch for operational metadata and Sentry for error reporting. These examples are not the full list; the published Global DPA and its Annex III identify the providers. On 29 September Featherless confirmed that public-cloud processing uses shared capacity across those providers, without a guaranteed location or per-account routing controls. The operator therefore cannot promise processing only in the USA or Switzerland. Featherless has not supplied ZeroLog with a complete metadata field list or field-specific retention periods beyond the published documents. Annex I(B)'s contract-duration-plus-30-days wording is not a verified deletion deadline for every metadata field. The same written confirmation expressly permits ZeroLog to offer the models to its own customers. These are statements by Featherless, not a technical zero-retention guarantee by ZeroLog. ZeroLog cannot enforce or verify that commitment for each request; the route remains classified as provider-stated in the service. No per-request zero-retention control is sent to Featherless. The provider serving each turn is shown with the turn.

Chats with credentials from the secrets vault. When you attach saved credentials to a chat, that chat is treated as a zero-data-retention chat. It runs only on a route whose zero-data-retention commitment is confirmed. For Featherless this is the written commitment of 28 September 2026 described above: a statement by the provider, not a guarantee that ZeroLog enforces technically. On any other route, or when the route cannot be determined, ZeroLog refuses the request and sends nothing to a provider. It does not move such a chat to another provider by itself: not after an error, not when a balance is empty, and not to continue an interrupted answer. You can allow it manually for one chat; the chat then shows that the override is active. You can revoke the override. Credentials that are part of a prompt still reach the model provider of that chat, because the model needs them to act. The vault protects them while they are stored.

SMTP2GO documents its server countries and account-region assignment. ZeroLog uses the global API endpoint; an EU-only route is not configured or promised. The account-specific DPA and safeguards for all onward transfers remain unverified. A New Zealand company address does not resolve that gap.

Your own accounts are not our sub-processors. Claude Code and Codex run inside your container. When you sign one in with your own Anthropic or OpenAI account, the tool talks to that vendor directly, under the contract you have with it: your subscription, your terms, the vendor's privacy policy. Your prompt and the files the tool reads go from your container to that vendor, not through Featherless. This is not a promise of confidentiality from ZeroLog: the chat integration processes the prompt and returns the tool's output through ZeroLog, and ordinary chat history and container storage remain technically accessible to the operator under the rules above. The operator is not the subscriber to your vendor account; it provides the container and network path. If you would rather send nothing to that vendor, do not sign it in.

Internal use only. Accounts of the operator's internal staff also use the providers below, for internal work on this service. These are not customer accounts. Customer accounts cannot pick their models, and customer content is not sent through ZeroLog's internal staff provider accounts, neither directly, nor as a fallback, nor by a background step. This does not exclude the provider-internal OpenRouter route listed by Featherless above. The table identifies ZeroLog's separate staff integrations; it does not override Featherless's subprocessor list.

Anthropic appears in both places: as a model provider only for the operator's own use, and in the first table for the error reports of §3.6, which are not customer prompts.

Memory. Memory is off by default and is switched on per chat (the optional encrypted memory described below works differently). When it is on, the service proposes facts to remember and keeps an entry only after you confirm it. Entries are stored in the account database on the operator's server in Switzerland, together with the chat they came from. Since 20 October 2026 they are encrypted there with a separate key per account (AES-256-GCM); the same applies to writing-style samples, agent memory and the agent journal. The account key is stored wrapped with a server key at the operator in Switzerland. This protects copies of the database and backups, but it is not end-to-end encryption: the running service decrypts entries to use them, and the operator can technically read them. When your account is deleted, its account key is deleted too, and encrypted entries left in backups can no longer be read. You can see, edit and delete every entry under Settings → Memory, and memory is never available in anonymous chats. When a memory is injected into a prompt, its text goes to Featherless like the rest of that prompt.

Encrypted memory (optional, separate from the memory above). Under Settings > Account & security > Encrypted memory you can set up a second memory. It does nothing until you set it up. Your browser creates the key and encrypts each entry with AES-256-GCM before upload. The key reaches us only wrapped under your passphrase and under a one-time recovery code (PBKDF2-SHA256, 600,000 iterations), so we receive neither the passphrase, the code nor the unwrapped key. We store the ciphertext and the wrapped keys. This protects the stored entries against a copy of the database, against backups and against the operator. That protection covers storage only. It is not end-to-end encryption, and entries are not hidden from the model when they are used: while this memory is unlocked and memory is switched on for the chat you are writing in, your browser selects matching entries (up to about 1,500 characters), decrypts them and sends them in plain text with the message. In a chat with memory switched off, and in anonymous chats, no entries are sent, and the server ignores them if a browser sends them anyway. The chat shows a notice with the number of entries that went along. A setting in your browser (on by default, stored per browser) stops the sending without locking the memory. Entries that are sent pass through Cloudflare, are processed in the memory of the server (not stored as a separate record; a reply that repeats them is stored like any chat message) and are forwarded with the prompt to the model provider of that chat, by default Featherless (§5). Locking the memory stops this. Anonymous chats never receive these entries. The button "Suggest memories from a recent chat" sends up to the last 30 messages of your most recent chat to a language model and shows you the suggestions before you decide to save them. The operator can see that you use the feature, how many entries you have, when they were created and changed, their approximate size and when your browser loads them. If you lose both passphrase and recovery code, the entries cannot be recovered and we cannot reset them. Anyone holding a copy of the database, a backup or your data export can try to guess the passphrase offline, so a weak passphrase weakens the protection. It does not protect against a compromised or manipulated web application. These entries are separate from the per-account server-side encryption above; the server key does not cover them and cannot open them. Deleting an entry removes it immediately; deleting your account removes all entries and wrapped keys; copies in backups stay encrypted until the backups expire (§8). Your data export contains the ciphertext and the wrapped keys, readable only with your passphrase or recovery code. Setup never overwrites an existing key: replacing it is a separate, explicit reset that deletes all entries. The passphrase must have at least 12 characters. New entries are bound to their row on the server (additional authenticated data), so the server cannot move a ciphertext to another row without detection; older entries stay as they were. Your browser discards the unlocked key when you sign out. The server no longer offers a search over plain-text vectors of entries; ranking happens in your browser.

Android phone jobs (screen sharing), only with your consent per job. In the ZeroLog Android app the AI can propose a job on your phone. Nothing runs until you start it and confirm Android's own screen-sharing consent for that job (MediaProjection). While the job runs, only apps on the job's allow-list are operated, and reading and gestures are blocked whenever another app is in front. For each step the app sends to ZeroLog, and as part of your prompt to the model provider of that chat (by default Featherless, §5), the texts it reads from an allowed app through the Android accessibility service and, if "send images to the AI" is on (it is on by default), screenshots of the screen taken while an allowed app is in front (JPEG, long edge at most 960 px). Screenshots go only to models that accept images; for other models they are replaced by a notice. Screen sharing ends with the job and also on pause, stop or takeover; resuming asks for new consent. ZeroLog does not store the screenshots: they are removed from the tool result before it is saved and are not kept in the chat history, only a caption. The texts read from the screen, the tool calls and the model's replies are stored in the chat the job belongs to, like any other tool result, and are kept as long as that chat (§8); deleting the chat deletes them. What the provider keeps is described in §5. Screens of allowed apps can show other people's data, so allow only apps in which you accept that the AI reads.

Browser extension (Chrome and Firefox) and browser AI bridge, both off by default. With the extension on, the page content, screenshots and console output of tabs you act on are sent to ZeroLog and, as part of your prompt, to Featherless; a short-lived token is stored in the extension. With the browser AI bridge on, you use your own third-party AI account through an ephemeral session. ZeroLog stores no credentials, the provider's terms and any account-ban risk are yours, and the feature shows a consent screen naming that risk before it runs.

WebHook AI. If you configure a webhook, the third-party URL you name receives event data about your runs. You choose the endpoint and are responsible for it.

Push notifications (§3.7). Notifications to the ZeroLog apps run through the operator's own ntfy server in Switzerland; no push provider is involved, only Cloudflare in transit. Browser notifications (Web Push) pass the push service of your browser's vendor (Google, Mozilla, Apple or Microsoft, all USA), end-to-end encrypted, so that service sees the push address and when a message arrives, not what it says. Your browser picks that service; ZeroLog does not.

Security processing. For abuse and fraud prevention ZeroLog processes your IP address, user agent and request metadata (legal basis: overriding/legitimate interest, Art. 6(1)(f) GDPR / Art. 31(1) revDSG). These security logs are kept 30 days (aggregates 12 months). The egress denylist is compiled from public hostname lists that contain no personal data.

Art. 19 para. 4 FADP requires that the state be named, not a region, which is why no row above says "global" or "worldwide". Cloudflare is the awkward case: a CDN terminates your request wherever you happen to be, so the honest statement is the rule that decides it (nearest edge location to you) rather than a list of every country Cloudflare operates in. Cloudflare, Inc. holds an active Swiss–US certification, so Art. 16 para. 1 covers the transfer to the company itself; the operator has not separately concluded standard data protection clauses under Art. 16 para. 2 lit. d, and does not claim to have.

Where the bases come from. Under Art. 16 para. 1 FADP a transfer needs no further safeguard if the Federal Council has found the destination adequate. The list is Annex 1 to the Data Protection Ordinance (DPO, SR 235.11, per Art. 8 para. 1 DPO). Germany, Ireland and New Zealand are on it, so IONOS (container egress and the encrypted backup copy), Stripe's European entity and SMTP2GO's New Zealand company are covered outright. For SMTP2GO this covers the company; the operator has not confirmed where its sending servers process a message, and this policy will name those countries and their basis once confirmed. Microsoft 365 is no longer used for mail: the code path for it (Microsoft Graph) is archived and switched off. The USA is on it only for organisations certified under the Swiss–US Data Privacy Framework: adequacy there is per organisation, never country-wide.

Checked against the official participant list on 31 July 2026 and again on 26 September 2026: Cloudflare, Inc. (record 5666), Google LLC (record 5780) and Stripe, LLC (record 10014) each hold an active Swiss–US certification (Cloudflare's is listed as "Active – re-certification under review"). Those three transfers therefore rest on Art. 16 para. 1.

Featherless: processing agreement and transfer safeguards are different. In its written confirmation of 29 September 2026, Featherless confirmed that the published Global DPA automatically applies to ZeroLog's Developer API account as part of its Terms of Service. An agreement governing processing under Art. 9 FADP / Art. 28 GDPR therefore exists in that form; there is no individually countersigned agreement. The current Global DPA and its annexes govern that processing. ZeroLog continues to use the Developer plan.

EEA/UK transfers. Section 13 of that DPA incorporates EU Standard Contractual Clauses (Module 2) for transfers from the EEA/UK. This is distinct from the processing agreement itself. The clauses do not establish a guaranteed processing location or eliminate the need to assess onward transfers and the laws of the processing countries. ZeroLog does not present the narrow contract-performance derogation in Art. 49(1)(b) GDPR as a durable basis for regular transfers.

Transfers from Switzerland. No Swiss Addendum has been agreed. Featherless declined to amend the published DPA for the Developer plan. Recursal AI / Featherless was not found on the Swiss–US Data Privacy Framework list in the operator's check of 25 September 2026, so ZeroLog does not claim that safeguard for Featherless. The operator relies on Art. 17(1)(b) FADP (contract performance) for the requested inference. Reliance on this exception for regular, systematic transfers is legally uncertain and disputed; it is not a confirmed equivalent to suitable transfer safeguards. Neither an account, the DPA, nor this disclosure proves that every transfer meets the exception's conditions. The unresolved transfer risk remains the operator's responsibility. It includes processing by Annex III providers in countries such as the USA and Singapore without a location guarantee. This policy does not claim Swiss SCC coverage, an adequate level of protection at every processing location, or a per-request technical guarantee by ZeroLog.

A limit worth stating. A Data Privacy Framework certification must be renewed annually, and a lapse removes the Art. 16 para. 1 basis for that recipient. On 26 September 2026 the list gives the next due dates as 13 September 2027 (Google), 15 September 2027 (Cloudflare) and 11 May 2027 (Stripe). Cloudflare's entry reads “Active – Re-certification under Review”: the annual renewal has been submitted and is being reviewed, and the certification stays active in the meantime. The operator re-checks the list at each due date; if one lapses, this policy is corrected rather than left standing.

A change of provider is announced here first. The operator may replace Featherless or add a second provider for customer accounts (Terms §12.1). Before any prompt goes to a provider not named in this section, this section names it, with its state and the transfer basis.

For text chat inference, assume that your prompt leaves Switzerland and can be processed in the USA and other countries used by Featherless's Annex III providers, including Singapore. The separately requested Infomaniak image generation is described in §3.2.1. If that is not acceptable for a particular piece of information, do not put it in a prompt, and consider an anonymous chat, which keeps the stored copy unreadable here even though the model still has to see the question.

No data is sold, rented, or shared for advertising.

6. Anonymous chats (zero-knowledge)

Anonymous chats are encrypted in your browser before they reach the server. The server stores only ciphertext plus the billing counters (tokens and cost) needed to charge you.

Consequences, stated plainly:

• The operator cannot read them, and cannot be compelled to produce their content, because the key never reaches the server.
• The operator cannot recover them. Lose the passphrase and the content is permanently gone.
• They cannot be moderated. Prohibited use is still prohibited (Terms §4). It simply cannot be detected there, and enforcement rests on other signals.
• Prompt content is still sent to the inference provider (Featherless) to get an answer. Encryption protects storage on this server, not the fact that a model must see the prompt.

7. Cookies

The main application uses the following three cookies, not for advertising or cross-site tracking. These required functions do not use a consent banner. The identity service and payment providers can set their own required session/security cookies on their domains; this is not a claim that the whole login and payment journey contains only three cookies.

All three set HttpOnly, Secure and SameSite=Lax, and the __Host- prefix means a browser accepts them only from this exact origin over HTTPS. The plain-language summary further down this page says exactly what the third one records and what it deliberately does not.

Local storage in your browser holds interface preferences (theme, language, layout, appearance settings and a copy of them that lets the page apply them before it is drawn) and, for anonymous chats, key material that never leaves your device.

8. How long data is kept

On account deletion, personal data is deleted or anonymised, except where retention is legally required (billing records above) or an abuse investigation is open. Your account number as the target of an administrator action in the operations log is not removed early; it expires after 30 days (§3.4.1).

9. Your rights

Under the FADP and, where applicable, the GDPR, you may request:

• Access: a copy of your data
• Rectification: correction of inaccurate data
• Erasure: deletion (subject to legal retention)
• Restriction and objection: including objection to processing based on legitimate interest
• Portability: your data in a machine-readable form
• Withdrawal of consent: for anything you consented to, with future effect

Write to info@zerolog.ch. A response follows within 30 days.

An honest limitation: most accounts carry no email address, and where none is on file identity cannot be verified by email. Requests are honoured by proving control of the account (logging in). If you cannot log in, the operator cannot safely identify you as the account holder and may have to refuse. Refusing is the privacy-preserving answer, since the alternative is handing your data to whoever asks.

Complaints. Switzerland: Federal Data Protection and Information Commissioner (FDPIC), Bern. EU/EEA: your national supervisory authority.

10. Security

Passwords are held by the sign-in service (§3.1), hashed with Argon2 and never stored in clear. Traffic is TLS-encrypted. Containers run in a sandbox (gVisor) with a restricted syscall profile and a network egress allow-list. When you create a container you can choose a stronger isolation class instead, where a server for it is available: a dedicated virtual machine, optionally with gVisor running inside it as well. This is a stronger floor, not a different data flow. Third-party keys are kept apart from the main application in the key service (§3.2.4). Access to the server is limited to the operator.

Network credentials of containers. A container reaches the internet through the egress gateway with a credential that belongs to that one container. The gateway checks that the credential matches the container it is presented from, refuses container types it does not know, and rejects the credentials of deleted or offloaded containers. The operator can rotate the credential of one workspace; the old one stops working at once and the container receives the new one when its runtime is recreated. One limit remains: containers on worker nodes reach the gateway through a tunnel that does not reveal their name, so this name check does not apply to them yet.

Runtime monitoring of workspaces. On the main server and on the worker servers that run containers, the open-source tool Falco watches the container sandboxes (gVisor) for a fixed list of suspicious behaviours, and for nothing else: a process with the name of a known coin miner; a connection to a typical mining-pool port; a shell, script interpreter or netcat wiring a network connection to its input or output (the core move of a reverse shell); a shell opening a network connection itself; running a program from /dev/shm; opening paths that must not exist inside a sandbox (other users' workspaces, the NAS, the application directory, the container runtime socket); attaching to another process with ptrace outside a debugger; reading /etc/shadow or /etc/gshadow; starting a network scanner; a direct connection attempt into a private network range; and a self-test rule with which the operator checks that the chain works. A match produces an event with these fields only: the rule with its category, priority and time, the container's identifier and name, the process name, the type of system call and, for network rules, the destination port. Command lines and arguments, environment variables, file names, file contents, network addresses, network payloads and chat content are not part of an event. A filter on each server drops every other field before the event leaves Falco. Events from the worker servers travel over an SSH connection to the main server. Nothing is written to disk on the way; if delivery fails, the event is discarded.

The application on the main server uses the container name only to find the workspace and does not keep it, nor the container identifier. It stores the event with two pseudonyms instead (keyed one-way hashes): one for the workspace and one for the account; for an anonymous chat, one derived from the chat's own random value instead of the account. A process name stays in clear only if it is on a fixed list of tools whose name is itself the finding (for example known miners, shells, curl, nmap); any other name is replaced by a hash. The events are kept in a database held in the main server's memory, not on disk. They are deleted after 90 days at the latest, earlier when the server restarts, and the oldest go first once 50,000 have accumulated. They are not written to log files, not sent to a monitoring server and not passed to any third party. Falco's own counters stay on the server where it runs.

Only the operator sees these events, in the admin security view; when the assessed level of a workspace rises, an entry appears on the operator's alert board. The application keeps a lookup table, in the same in-memory database, that turns the workspace pseudonym back into the workspace, and the workspace belongs to an account. The operator can therefore tie an event to an account: the events are pseudonymous, not anonymous. At present these events trigger no automatic restriction of a workspace; the operator decides what follows. Deleting your account does not remove existing events early; they expire as described above.

Related decisions have a separate limit of up to 365 days. State, mappings and admin alerts have no fixed time limit but also live only in that volatile database. A host restart removes them; append-only tables are capped at 50,000 rows. The event limit of 90 days therefore does not apply to all security metadata.

The purpose is to detect abuse of the service from a container (for example coin mining or attacks on others) and attempts to break out of the sandbox. This is part of the data security the operator owes under Art. 8 FADP; the legal basis is listed in §4 (security and abuse prevention).

Separate host monitoring and temporary SSH blocking (Wazuh). Since 15 October 2026, the operator also monitors its own participating servers using a self-hosted Wazuh installation in Switzerland. This is separate from the Falco event store above. A filter reconstructs SSH success and failure events with source IP, source port, authentication method and the category root or account, without the other account names or raw journal text. It also reports selected security service stops. Host inventory includes operating system, installed packages, hardware and listening ports. Integrity checks record paths, hashes and metadata of selected system/security files, without file contents or diffs; the integrity-monitor configuration excludes customer workspace and home directories. It is not a general upload of chat, files or raw application logs.

These records reach the operator's central manager through an encrypted private network. Only the operator has dashboard access. Repeated SSH authentication failures can automatically block the source IP on TCP port 22 for 60 seconds, with exceptions for the required administration and service connections. The operator can disable the response and review false positives. It does not automatically suspend a customer account or apply the Falco workspace restriction levels. Central alert indexes expire after 14 days under the configured cleanup policy; local reconstructed-event and response logs rotate daily with a 14-day maximum age. A failed cleanup can delay deletion. Current inventory and protected infrastructure backups have separate lifecycles. Wazuh software updates and vulnerability feeds are downloaded; this configuration does not upload those host records to Wazuh's cloud service. The purpose and basis are security/abuse prevention in §4.

Stated plainly: this is a service run by one person on self-hosted hardware. Reasonable measures are taken, but no absolute security can be promised, and you should not store data here whose exposure you could not tolerate.

11. Children

The service is not directed at children under 16 and accounts require the user to be 16 or older (Terms §3.1). No data is knowingly processed from children under that age.

12. Changes

This policy may be updated. The version and date at the top always reflect the current text. Material changes are announced in the app. The full German and English texts are intended to describe the same facts; translation differences do not change actual processing or mandatory law.

1. What this is

These Terms govern your use of ZeroLog (zerolog.ch and its subdomains), a self-hosted AI workspace that gives you chat access to third-party AI models, real Linux containers, public network ports, and autonomous agents that can run commands on your behalf.

By creating an account or using the service you accept these Terms. If you do not accept them, do not use the service.

The service is operated by a single natural person in Switzerland, not a company. It is provided in the operator's own name and on the operator's own hardware.

2. The service, described honestly

ZeroLog gives you:

• AI chat against open-weight models served by a third-party inference provider. For customer accounts that is currently one provider, Featherless (USA), and the model picker shows only models it serves. Which provider this is, and which models it offers, can change (§12.1); the Privacy Policy names its processing countries and limitations. ZeroLog does not reroute a failed customer request through its other provider accounts. Featherless itself lists subprocessors, including OpenRouter as a possible fallback, and provides no location or per-account routing guarantee on the Developer plan. Your prompts leave this server for that processing. ZeroLog's separate internal staff provider accounts are not available to customers.
• Image generation (optional, separate feature): image prompts go to Infomaniak (Switzerland). The Privacy Policy describes what is sent and how long results are kept.
• Your own AI accounts. You may sign the Claude Code or Codex command-line tools in your container into your own account with that vendor. That use runs under your contract with the vendor, at your cost and under its terms, not under a contract between the operator and the vendor. The operator provides the container and the network path, and is not responsible for what the vendor does with it.
• Linux containers running under a sandbox (gVisor). You get root inside your own container.
• Public ports: you may expose a service on a *.zerolog.ch hostname. Anything you publish there is reachable by the public internet and is published in the operator's name and from the operator's IP addresses.
• Preview links. A service running in your container (for example an app or site the AI built) can also be viewed through a private preview address that is not posted as a *.zerolog.ch hostname and does not count against a public-port quota. That address carries a capability token instead of a login: whoever has the link can view what is running there until the link expires (7 days by default; when you create one yourself you can choose 1 hour, 24 hours, 7 days or 30 days) or you revoke it, and only while the container exists and runs. Expiry and revocation stop new requests and new connections; a live connection opened before is not cut off. Sharing such a link is, for that purpose, the same as publishing it; §4.9 applies to what you put behind it.
• Key proxy. You may store API keys for third-party services in a separate key service, so that agents use them through placeholders and ask for your approval where a key's rule requires it. The Privacy Policy describes what is stored and for how long.
• Autonomous agents (/goal, scheduled tasks) that continue to run commands without you watching, on instructions you gave.
• Outbound network access via an egress gateway, which may route through infrastructure in other countries.

This is a hobby-scale service run by one person. There is no uptime guarantee, no support guarantee, and no guarantee that your data survives. See §9 and §10.

3. Account and eligibility

3.1 You must be at least 16 years old. If you are under 18, you may only use the service with the consent of a parent or legal guardian.

3.2 Accounts use ZeroLog's own Keycloak identity service. An account email address is optional and empty by default; you may add or remove it as described in Privacy §3.1. Without a usable recovery address or another recovery method you have set up, the operator cannot promise to restore your access. This is separate from the preview waitlist, which requires an email address. Public self-registration is currently closed; access is by invitation or operator-created account.

3.3 You are responsible for everything that happens under your account, including actions taken by agents you started and by anyone you share a container or workspace with.

3.4 One person may not operate accounts to evade a suspension, a quota, or a spend limit.

4. Acceptable Use Policy

This section is the core of these Terms. It exists because the operator's name, hardware, IP addresses and legal identity stand behind everything you do here.

You must not use ZeroLog, its containers, its agents, its network or its models to:

4.1 Attack, disrupt or overload anyone

• Denial-of-service or distributed-denial-of-service attacks of any kind, including tests, simulations, demonstrations, stress tests and "load tests" against systems you do not own.
• Traffic floods, amplification or reflection attacks, or any traffic intended to exhaust another party's bandwidth, connections, CPU or memory.
• Operating, hosting or controlling a botnet, command-and-control server, stresser/booter service, or a proxy or relay used to conceal attack traffic.
• Port scanning, vulnerability scanning, fuzzing, brute-force or credential-stuffing attacks against systems you do not own and do not have written authorisation to test.

4.2 Create or distribute malicious software

• Writing, compiling, building, packing, obfuscating, testing, hosting or distributing malware, including ransomware, wipers, worms, trojans, rootkits, bootkits, keyloggers, info-stealers, banking trojans, RATs, droppers, loaders and exploit kits.
• Developing or weaponising exploits for vulnerabilities in systems you do not own.
• Building tooling whose primary purpose is to defeat antivirus, EDR, sandbox detection or other security controls.
• Hosting or distributing stolen credentials, stolen data, card data, or dumps.

On security research: defensive security work, CTF challenges, malware analysis in an isolated container, and testing of systems you demonstrably own or are contracted to test are permitted. The line is authorisation and intent, not subject matter. If you are doing security work, be prepared to evidence your authorisation on request. Automated scanning may flag your activity; if it does, the burden is on you to show the work was authorised.

4.3 Gain or attempt unauthorised access

• Accessing or attempting to access any account, container, workspace, network, database or system that is not yours.
• Escaping or attempting to escape the container sandbox, the hypervisor, or the egress controls.
• Circumventing quotas, spend limits, rate limits, the egress allow-list, or any access control of this service.
• Intercepting, sniffing or altering traffic that is not yours.

4.4 Commit crimes or infringe rights

• Any activity unlawful under Swiss law or the law that applies to you.
• Fraud, phishing, identity theft, social engineering, or impersonating a person or organisation.
• Producing fake identity documents, forged records, counterfeit goods, or deceptive material intended to pass as genuine.
• Infringing copyright, trademarks, patents, trade secrets, or personality rights, including hosting or distributing pirated media or software.
• Unsolicited bulk messaging (spam) of any kind, and harvesting contact data for that purpose.

4.5 Produce or handle prohibited content

• Child sexual abuse material: created, stored, transmitted, processed or generated. This is reported to the authorities without notice to you.
• Content that incites, promotes, organises or provides operational assistance to terrorism, violent extremism or serious violence against people.
• Instructions for producing weapons, explosives, or chemical, biological, radiological or nuclear agents intended to cause harm.
• Non-consensual intimate imagery, including synthetic imagery of real people.
• Targeted harassment, stalking, doxxing or threats against a person.
• Racial, ethnic, religious or sexual-orientation hatred and discrimination, and the denial or gross trivialisation of genocide or other crimes against humanity (Art. 261bis of the Swiss Criminal Code). Published from this service, that content makes the operator its publisher, which is why it is named here rather than left to the general prohibition above.

4.6 Abuse the models

• Attempting to circumvent the safety controls of a model or of this service in order to obtain output that is otherwise prohibited by this section ("jailbreaking").
• Reselling or redistributing model access, or operating the service as an inference proxy for third parties, unless expressly agreed in writing.
• Automated scraping or bulk extraction of model output for the purpose of training a competing model, where the upstream provider's terms forbid it.

4.7 Abuse the resources

• Cryptocurrency mining, coin-hashing, or proof-of-work computation of any kind.
• Deliberately wasteful workloads whose purpose is to consume capacity rather than to produce a result.
• Using the egress gateway to anonymise activity that would breach this section.

4.8 Sanctions and export control

The operator supplies compute, model access and cross-border network egress. You must not use the service if you are subject to Swiss, EU, UK or US sanctions, nor make it available to a person or entity that is, nor use it in or for the benefit of a comprehensively sanctioned territory. You are responsible for any export-control obligation that attaches to what you build or transmit here.

4.9 Public ports and preview links carry extra duties

Anything you expose on a *.zerolog.ch hostname is published in the operator's name. You must not publish there: malware distribution points, phishing pages, illegal marketplaces, CSAM, or infringing content. Abuse complaints about a published port land with the operator, and will result in immediate closure of that port. The same rules apply to anything reachable through a preview link (§2): a capability link that anyone holding it can open is, for this section, a publication, and an abuse complaint about one is handled the same way. The publication ends when the link expires or is revoked. On an abuse complaint the operator acts under §6.2, for example by suspending the account, after which no preview link of that account accepts new requests.

5. You are responsible for your agents

ZeroLog can run agents that continue working autonomously for hours on a goal you set.

An agent's actions are your actions. You accept full responsibility for everything an agent does under your account, including outcomes you did not specifically foresee. "The AI did it" is not a defence, and the operator does not accept it as one. If you cannot supervise an agent, do not start it.

The same applies to anyone you invite to a container or workspace: their actions under your resources are your responsibility toward the operator.

This holds unchanged when an agent reaches a third-party service through the key proxy: the operation runs under your key and in your name, even when the key service intercepts, checks or rewrites it. If you switch on full access for a key, including approval-free payments, you carry the consequences of every operation that runs under that key, with no single approval left to confirm it.

6. Enforcement

6.1 Investigation. The operator may investigate suspected breaches of §4, including inspecting container contents, network flows and logs where technically possible. Anonymous (client-side encrypted) chats cannot be inspected. See the Privacy Policy.

6.2 Immediate suspension. The operator may suspend or terminate your account, stop your containers, close your ports and cut your network access immediately and without prior notice where there is a reasonable suspicion of a breach of §4, or where your use creates a security risk, a legal risk, or a risk to the service or other users. There is no obligation to warn first.

6.3 Preservation and disclosure. Where required by Swiss law or by a lawful order from a Swiss authority, the operator will preserve and disclose data. In cases involving CSAM or an imminent threat to life, the operator will report to the authorities proactively.

6.4 Costs. Where your breach causes the operator direct costs (abuse handling, IP reputation damage, blocklisting, upstream provider penalties, legal fees), those costs are recoverable from you under §8.

6.5 Termination for breach. Subscription fees for the current period are not refunded where an account is terminated under §4. Unused prepaid credit is refunded less the operator's documented costs arising from the breach (abuse handling, upstream penalties, legal costs). Credit is not forfeited as a penalty: a Swiss court reduces an excessive contractual penalty in any case (Art. 163 para. 3 CO), so this states what the operator would actually be able to keep.

7. Payment, credit and refunds

7.1 ZeroLog has five plans: Free, Mini, Pro, Max and Ultra. Free is an account without a container and costs CHF 0. Mini (CHF 9 per month or CHF 90 per year), Pro (CHF 15 per month or CHF 150 per year), Max (CHF 24 per month or CHF 240 per year) and Ultra (CHF 79 per month or CHF 790 per year) include the containers, tools and monthly model credit stated on the pricing page and at checkout. A plan can be bought once the pricing page or the checkout shows it as available; a plan marked "coming soon" cannot be bought yet. A yearly price covers twelve months and is paid in advance. All prices are in Swiss francs. Subscriptions are billed by Stripe and renew for the same period, monthly or yearly, until you cancel. An account holds one subscription; a plan change replaces it and can create a prorated charge or credit shown by Stripe. Credit included in a plan is granted after a successful invoice, is spent before credit you bought or topped up, and expires three months after it was granted. It is not redeemable for cash and cannot be transferred to another account or person. Credit you bought or topped up is not affected by this expiry and follows §7.2 and §12.3.

7.1a Autonomous runs (for example /goal) have a time limit per run. It is not a monthly allowance: a run may last up to 4 hours on Mini, up to 8 hours on Pro and up to 12 hours on Max. A run that reaches its limit is ended, and the chat says so; you can then start a new run. Ultra has no limit per run. Free has no autonomous runs.

7.1b On Pro, Max and Ultra you can add a Compute Boost for CHF 12 per month, up to two per account. Each boost adds 2 vCPU, 8 GB RAM and 25 GB SSD. A boost is a separate monthly purchase next to the plan, billed by Stripe, and you can cancel it for the end of the month already paid. Mini has no boost. Like a plan, a boost can be bought once the checkout shows it as available.

7.2 Manual credit top-ups run through MoonPay Commerce / Helio, with the available payment methods, identity checks, minimum and fees shown at checkout. Proceeds settle as USDC to the operator's configured wallet, currently a custodial Bybit wallet; this is not the customer's wallet and not a claim of operator self-custody. Stripe handles recurring plans. Card details are handled by the payment providers, not stored by ZeroLog. A manual top-up currently has a 3% currency buffer and no ZeroLog top-up service fee. Provider checkout fees may be additional and are shown before payment. Token prices include the provider rate plus a 2% service margin. Subscription credit packages have their own published price and allocation; the manual top-up formula does not replace that package price. Model usage on your own provider account is billed under that provider's terms. Prepaid credit pays for eligible service usage and is not redeemable for cash while the account remains open; refunds on termination follow §12.3.

VAT: Not liable for Swiss VAT (Art. 10(2)(a) VAT Act); no VAT is charged. Any separate payment-provider charges are shown at checkout.

7.3 Prices and model rates may change. Rate changes for models follow the upstream provider and can take effect without notice, because they are not the operator's prices.

7.4 You are responsible for spend you cause, including spend caused by an agent running autonomously. Spend limits are a convenience, not a guarantee; do not rely on them as your only control.

7.5 Statutory withdrawal rights, where they apply to you as a consumer, are unaffected.

8. Your indemnity to the operator

This clause is the reason these Terms exist.

You will defend, indemnify and hold harmless the operator against any claim, demand, proceeding, loss, damage, fine, penalty, and reasonable legal and abuse-handling costs arising out of or connected with:

(a) your use of the service, including anything done by an agent under your account or by any person you gave access to; (b) your breach of these Terms, and in particular of §4; (c) content you generate, store, publish or transmit through the service; (d) your infringement of a third party's rights; and (e) any claim by a third party that your activity harmed them, their systems or their data.

Limits on this indemnity. Where you are a consumer, this obligation is capped at the same amount that limits the operator's liability to you under §10.2. The two sides are deliberately symmetrical: a duty on you far larger than the operator's own ceiling is the imbalance Art. 8 UCA (UWG) exists to strike, and a clause that is struck protects nobody. It does not apply where the loss was caused by the operator's own intent or gross negligence, nor to the operator's own regulatory fines (Art. 20 CO: an agreement to shift somebody else's penalty onto you is void, and including it would put the rest of this clause at risk). It applies in full where you use the service in a professional or commercial capacity, where Art. 8 UCA does not apply.

This survives termination of your account.

9. No warranty

The service is provided "as is" and "as available", with no warranty of any kind, express or implied, including merchantability, fitness for a particular purpose, non-infringement, availability, or accuracy of model output.

Specifically not warranted:

• that the service will be available, uninterrupted, or performant;
• that your data, containers, files or chat history will survive, so keep your own backups;
• that model output is correct, lawful, safe, non-infringing or fit for any purpose;
• that a sandbox or an isolation boundary is impenetrable;
• that a third-party provider (inference, payment, network) will continue to be available.

AI output is not advice. Output from this service is not legal, medical, financial, tax or professional advice, and must not be relied on as such.

10. Limitation of liability

10.1 To the fullest extent permitted by Swiss law, the operator is not liable for indirect, incidental, consequential or special damage, lost profit, lost data, business interruption, or reputational harm.

10.2 The operator's aggregate liability arising from or connected with the service is limited to the total amount you paid in the twelve (12) months before the event giving rise to the claim, or CHF 50, whichever is greater.

10.3 What cannot be excluded. Nothing in these Terms excludes or limits liability for intent or gross negligence (Art. 100 CO), for personal injury or death, or any other liability that cannot be limited under mandatory Swiss law. Where you are a consumer, mandatory consumer protections of your country of residence are unaffected.

10.4 Subject to §10.3 and mandatory law, the operator does not warrant the independent conduct or availability of third-party providers or other users. This does not exclude responsibility for the operator's own selection, configuration, instructions or other duties, nor liability for auxiliaries where it cannot lawfully be excluded.

11. Your content and data

11.1 Your content stays yours. You grant the operator only the technical licence needed to run the service: to store, transmit, process and display your content for the purpose of providing it to you, and to transmit prompts to the inference provider that serves the model you use.

11.2 The operator does not use your content to train models and does not sell it.

11.3 On account deletion, your data is deleted as described in the Privacy Policy. Backups and legally required records may persist for a limited period.

11.4 Anonymous chats are encrypted in your browser. The operator cannot read, recover, export or restore them. If you lose the passphrase, the content is gone permanently, and no support request can change that.

12. Availability, changes and termination

12.1 The operator may change, restrict or discontinue any feature at any time, including discontinuing the service entirely. Reasonable notice will be given where feasible; where a provider, a cost, or a legal obligation forces the operator's hand, it may not be.

This includes which inference provider serves the models and which models are offered. No particular provider, model or number of models is promised. Two limits apply to a change of provider. First, before any prompt goes to a new provider, the Privacy Policy names it, with its country and the basis for the transfer; a provider change never happens silently in the data flow, even where it happens without advance notice in the product. Second, credit you have already paid for is not lost when a model disappears: it stays usable on the models that remain, and §12.3 applies if you would rather leave.

12.2 The operator changes these Terms only for a valid reason: a change in the law, a decision of a court or an authority, security or the prevention of abuse, a change made by an inference or payment provider, the technical development of the service, a new or changed plan or feature, or a change in costs the operator cannot absorb. Every notice names the new version and its effective date. It is given in the app and, where your account has an email address, by email; the new version can always be downloaded and kept. The date printed on the document is not itself proof that notice was delivered. The version you accepted remains recorded. No change applies retroactively. How much notice you get depends on what the change affects:

• Paid plans and paid add-ons (including the Compute Boost and prepaid credit): a material change that disadvantages you is announced at least 30 days before it takes effect. You may terminate free of charge before the effective date, and in any case within 30 days after you receive the notice or after the change takes effect, whichever is later; the unused part of a prepaid period is then refunded pro rata under §12.3. A price change never applies to a period you have already paid for. If you have a paid plan or a paid add-on, this rule covers everything it includes.
• Free plan, free features and features marked preview or beta: a material change that disadvantages you is announced at least 14 days in advance. You may close your account at any time, free of charge.
• Immediate effect, with notice no later than when the change takes effect: changes solely in your favour; changes required by law, a court or an authority; changes needed to address security incidents or abuse; and purely editorial changes that do not change rights or duties. If such a change disadvantages you on a paid plan or a paid add-on, the free termination and refund right in the first point applies, counted from the notice.

Continued use after the notified effective date counts as acceptance only to the extent permitted by applicable law. Mandatory requirements for express agreement remain unaffected. Where mandatory consumer law gives you more, for consumers in the EU in particular Art. 19 of Directive (EU) 2019/770 as implemented in your country of residence, that law applies.

12.3 You may terminate at any time. Cancelling renewal normally leaves the paid subscription available until the end of its period. On account closure, unused separately purchased prepaid credit is refunded on request, less amounts already owed. If the operator discontinues paid service, or you terminate because you reject a material change under §12.2, the unused part of a prepaid subscription period is also refunded pro rata. An ordinary voluntary cancellation does not automatically refund an already started period while its service remains available. Credit included in a subscription is part of that subscription, not a second cash refund on top of its prorated refund. Valid refunds are paid within 30 days after the request and the information necessary to return the payment are received, normally through the original payment route. §6.5 governs termination for breach, subject to mandatory law; statutory consumer rights are unaffected.

13. Governing law and venue

13.1 These Terms are governed by Swiss law, excluding its conflict-of-law rules and the CISG.

13.2 The place of jurisdiction is Baden, Canton of Aargau, Switzerland.

13.3 If you are a consumer, this does not bind you. Art. 32 of the Swiss Civil Procedure Code gives you the choice of the court at your own domicile or at the operator's, and Art. 35 para. 1 lit. a ZPO makes that right one you cannot waive in advance. If you live in the EU, Iceland or Norway, Art. 15-17 of the Lugano Convention give you the same protection where its conditions apply. Art. 114 of the Swiss Private International Law Act (IPRG) also preserves the applicable consumer places of jurisdiction and prohibits advance waiver of the protected consumer domicile forum. §13.2 does not override these mandatory rules.

13.4 The choice of law in §13.1 has the same limit. Where Art. 120 of the Swiss Private International Law Act (IPRG) applies to you as a consumer, the law of the state of your habitual residence governs instead, and a choice of law is excluded; where EU law applies to you, the mandatory consumer protections of your residence remain applicable notwithstanding §13.1 (Art. 6 para. 2 Rome I Regulation).

14. Miscellaneous

14.1 If a provision is invalid, the rest stays in force and the invalid provision is replaced by one closest to its economic intent.

14.2 No rights may be transferred by you without consent. The operator may transfer this agreement as part of a transfer of the service, with notice.

14.3 Failure to enforce a provision is not a waiver of it.

14.4 These Terms are published in full in German and English with the same intended content. If the versions differ, the German version takes precedence, subject to mandatory law, the interpretation most favourable to a consumer where required, and any individually agreed term. A translation difference does not remove mandatory rights.

Report abuse: info@zerolog.ch. Include the hostname, IP, timestamp (with timezone) and evidence. Abuse reports about *.zerolog.ch are acted on.

Legal Notice

Version: 2026-10-15

Operator

Gian-Luca Luongo

Dorfstrasse 77

5430 Wettingen, Switzerland

Email: info@zerolog.ch

Natural person, not entered in the commercial register; not a company. Not liable for Swiss VAT (Art. 10(2)(a) VAT Act); no VAT is charged.

Gian-Luca Luongo is responsible for the operator's own content at the address above.

Service

ZeroLog at zerolog.ch and its subdomains provides a self-hosted AI workspace with third-party models, Linux containers and autonomous agents.

Legal documents

• Terms of Service and Acceptable Use Policy
• Privacy Policy

Abuse reports

Report abuse from zerolog.ch or its subdomains to info@zerolog.ch, with hostname or IP, timestamp including timezone, and suitable evidence. Confirmed abuse can lead to immediate account suspension.

Unlawful content

Notices should identify the content, URL, legal basis of the complaint and contact details. Unlawful content is removed once sufficiently substantiated.

Content, links and liability

The operator prepares its content with care but, to the extent legally permitted, does not warrant accuracy, completeness or timeliness. AI output can be wrong and is not professional advice. Terms §§9–10 apply, including their reservations for mandatory liability.

User content, containers and published subdomain services are not completely reviewed in advance and are not the operator's own content. The publishing user is primarily responsible. The operator's own statutory duties to investigate, respond and accept liability remain unaffected. External links lead to third-party content; mandatory duties remain unaffected there too.

Copyright

Unless otherwise stated, the operator holds the rights to the design, text and source code. User content remains with its respective rights holders.

Disputes

There is no voluntary commitment to consumer arbitration. This does not exclude any statutory obligation. Swiss law applies subject to Terms §13. Baden, Canton of Aargau, is the venue only where mandatory consumer venues and applicable conflict-of-law rules do not take precedence.

This notice is accessible without signing in. Search-engine indexing is not a condition for that access; the page currently uses noindex.