Last updated: 2026-08-18
1. Status and Scope
This page records the third parties selected for, present in, or conditionally planned for Notavia as of the lastUpdated date. Notavia is not yet generally available. As of 15 August 2026 this website and the documentation site are reachable from the public internet, and one payment-provider webhook path is answerable so that billing can be verified; the managed service itself — the application, its API, the preference centre, the tracking endpoints and the operator consoles — remains reachable only over a private network. No Customer exists, and no Recipient data has been processed for a Customer.
Several vendors are now marked in use, meaning the service is deployed and processing on that vendor. That is a statement about deployment only. A status of selected or conditional does not mean that an account, server, region, agreement, data-processing addendum, or transfer safeguard has been activated or verified — and in use does not mean any of the contractual items has been verified either. Where a vendor is in use and its contract or transfer position is still unevidenced, the row says so, and that is an open gap rather than a pre-activation gate.
We use five classifications:
- a Recipient-data subprocessor processes personal data in message content, Recipient records, delivery events, suppression records, or full service backups on our behalf when we process that data for a Customer;
- an account or site-data processor processes visitor, member, account, device, deployment, or operational data on our behalf without being intended to receive Recipient data;
- an independent controller determines its own purposes and obligations for a separate activity, such as payment and tax administration;
- a Customer-selected connected provider acts under the Customer's agreement when the Customer connects its own provider account; and
- an operational vendor with no intended personal-data access supplies software, images, or infrastructure tooling that is not intended to receive Customer or Recipient personal data.
The same company can have different classifications for different products. A public contract, DPA, security page, location label, or certification claim is evidence about the vendor's published offering; it is not evidence that Tessora LLC has accepted that contract, obtained that region, completed a security review, or received an audit report.
The DPA version identified in an organisation's acceptance record and its frozen Subprocessor Schedule remain the accepted terms for that organisation. This versioned page does not silently amend an accepted DPA. A material schedule change must follow the notice, objection, versioning, and reacceptance rules below.
Data location is separate from a Customer's billing country, selected currency, and applicable law. Notavia remains intended for worldwide business use. No legal-region selector, country allow-list, or EEA/UK exclusion is introduced by this list.
2. Recipient-Data Subprocessors
| Vendor and product | Status | Purpose and data | Verified location and access position | Contract and transfer position |
|---|---|---|---|---|
| Hetzner Online GmbH — Hetzner Cloud | In use; the production server is provisioned and running | Application and database hosting. The deployment holds account data, Recipient data, message content, delivery events, suppression data, credentials, exports, and self-hosted logs. | Germany, Falkenstein (fsn1). The server exists and production runs on it. Vendor support or administrative access must be treated as possible until the account and support controls are reviewed. | No executed DPA or account contract is evidenced. No Chapter V mechanism is claimed for German storage. Any access from another country must be assessed before launch. |
| Amazon Web Services, Inc. — Amazon Simple Email Service | In use; production sending access is granted and real mail has been sent | Managed email relay, bounce and complaint processing, and suppression management. Data can include Recipient email addresses, message content and headers, delivery metadata, complaint and bounce data, and suppression entries. Open and click tracking is not used: SES account-level engagement tracking is disabled, and no configuration set enables TrackingOptions. | Frankfurt (eu-central-1), confirmed by the granted per-region production access and by the feedback MX records for that region. AWS lists A100 ROW GmbH as the infrastructure provider for that region. The AWS account's contracting entity, support access, and final configuration have not been verified. | No executed AWS DPA or account acceptance evidence is recorded. This list and the DPA schedule now both describe the eu-central-1 route; the earlier us-east-1 description was a code default that production overrides. No adequacy or SCC coverage is claimed merely from AWS's public documents. |
| Cloudflare, Inc. — R2 | In use; the bucket, credentials and the nightly backup job exist, backups are running, and a restore has been rehearsed | Encrypted off-site backup of the entire production database. A backup is therefore a copy of all customer data the service holds in that database — Customer organisation and member account records, Recipient records, message content, delivery and engagement events, suppression entries, billing references, audit records, and configuration. Nothing is excluded from the dump, so every category described elsewhere in this list also exists inside these objects. | The bucket was created with a European location hint. That hint is best-effort and is not a residency guarantee; no storage jurisdiction is contractually verified. R2 does not provide S3 Object Lock and none is claimed here. What is in force instead is a bucket-level retention lock with a 14-day age, combined with a 14-day lifecycle rule: for the first 14 days after an object is written, both deletion and overwrite of that object are refused with 409 ObjectLockedByBucketPolicy, after which the lifecycle rule expires it. A backup is therefore immutable for 14 days and then removed, and the backup script no longer prunes the remote copy itself. This was established by observing that refusal on both operations, not read off a dashboard. Support and administrative access must be treated as possible until reviewed. | No executed Cloudflare DPA or account contract is evidenced for R2. Any access or processing outside the EEA/UK remains unclassified and unsupported. Because backups are now live, this is an open gap rather than a pre-activation gate. |
3. Account and Site-Data Processors
These services are not intended to receive Recipient message content or Recipient lists. A defect, support disclosure, log entry, or broad browser integration can expand that position and must be treated as an incident or vendor-scope change.
| Vendor and product | Status | Purpose and data | Location and access position | Contract and review position |
|---|---|---|---|---|
| PostHog, Inc. — PostHog Cloud | Active from 18 August 2026, on both routes, after the vendor conditions in the later columns were verified and this row was corrected in the same release. The website's production build passes the PostHog browser key from that date; the browser client still initialises only after a visitor accepts analytics — that gate is in the code, applies worldwide, and a rejection or absent choice keeps the client uninitialised regardless of the key. The server route carries a production key from the same date and sends only the allow-listed organisation-keyed events described in the next column. Between 15 and 18 August 2026 the build carried an empty key and nothing was collected; earlier versions of this row record that history. | The opt-in website route receives, after consent, page-view, page-leave, autocaptured interaction, browser/device, referrer, IP-derived, and persistent anonymous-identifier data, plus waitlist_submitted with source and contact_submitted with topic. The code disables session recording, enables the client Do-Not-Track option, and limits person profiles to identified users, but it does not identify website visitors. A separate server route currently has five organisation-keyed event call sites and properties: registration (plan, region), first notification (channel), API-key creation (environment, scope), plan change (plan, previous_plan, status), and first inbox render (none). It adds the organisation UUID as distinct_id and group; reviewed call sites contain no name, email, message content, Recipient data, person identifier, or hidden payload. A code-level allow-list enforces that list — the sending code refuses an undeclared event or property and refuses a value that is not a short plain token, refusing outright rather than trimming, with regression tests over the list and the call sites — and an organisation can record an objection in the dashboard that the sending code checks before every send. Both run in the image production serves. | The project's console settings were verified by the accountable owner on 18 August 2026: the console's own region field reads EU Cloud, for which PostHog's public subprocessor list places AWS storage in Germany, with additional core infrastructure processing including global Cloudflare transit; retention follows the plan-defined schedule, with log retention at its 14-day default and person deletion available in the console; support access was reviewed — the current tier exposes no customer-facing control, so vendor staff access is governed by the executed agreement below; IP discard is on, session replay, surveys, and feature-flag persistence are off; and both production domains are authorised. Evidence captures are filed in the internal evidence register (posthog-activation-2026-08-18). | A data processing agreement with PostHog Inc. was executed by both parties on 13 August 2026. It incorporates the EU Standard Contractual Clauses (Commission Decision (EU) 2021/914) on Module Two only, the UK Addendum, and Swiss FADP terms naming the FDPIC as competent authority where the FADP governs. The signed agreement is held by Tessora LLC and is not reproduced on this page; a Customer may request evidence of it under the DPA. That closed the contract and transfer-instrument gates for this vendor. PostHog's current public terms permit prospective Customer Content use for product and model development unless the customer opts out in service settings or agrees otherwise; our opt-out was exercised in service settings and verified on 18 August 2026. Website analytics is worldwide opt-in behind the consent gate, on the authorised production domain. The server route is legitimate-interests based and separate from website consent; its two implementation conditions — an enforced event/property allow-list and an operational objection route — run in the image production serves. All vendor conditions for this row are now recorded and role-approved, and both routes are active from 18 August 2026. |
| Cloudflare, Inc. — authoritative DNS | DNS is in use. No anti-bot challenge service is in use, and no Cloudflare asset CDN is in use. A Turnstile production site key, secret and account exist and were verified against siteverify, and an earlier website release did build the site key into its image and request the challenge script on both public form pages. That script has been removed. No page of the website now requests it, and no submission is checked against it. The removal was made rather than the control completed: the released code had no activation switch, no expected-hostname check and no check that a token was minted for the form it was submitted with, so the script collected from every visitor to those two pages while gating nothing. The deployment settings went with it — the three Turnstile variables in the production configuration were read by no released or deployed build and have been removed, so no setting remains that could switch a challenge back on. cdnjs was removed on 15 August 2026 and is recorded in section 6. | DNS processes hostnames, query and operational data. The website and the console contact Cloudflare for no purpose on any page. No Recipient data is intended. | DNS uses Cloudflare's global systems and may involve United States or other-country access. Request routing, support access, and retention for our account are unverified. No claim is made that the production origin is proxied through Cloudflare's CDN; the planned origin edge is Caddy. | No executed Cloudflare DPA or account-contract evidence is recorded, and DNS is in use without one. Reintroducing a challenge or an asset CDN is a decision, not a configuration change. A challenge would require fail-closed Siteverify validation, expected action and hostname checks, and captured account-specific contract, transfer, retention, deletion, subprocessor, access and security evidence — published here before it is switched on. |
| Volentio JSD Limited — jsDelivr public CDN | Removed 15 August 2026. Not in use. | Until that date two signed-in console pages — the data-export download page and the organisation-onboarding page — fetched Bootstrap from cdn.jsdelivr.net, which disclosed the IP address, user agent, request metadata and requested asset URL of a signed-in user to a third party we had no agreement with. Those assets are served from our own origin now, and no page of the console or the website requests anything from jsDelivr. No Recipient data was ever intended or sent. | Not applicable while unused. Delivery used a global network with a published chain including Cloudflare, Fastly and Gcore, and exact routing was never under our control. | We never had a subscription or an executed DPA, which is why the dependency was removed rather than papered over. Reintroducing it would require an agreement, a location and subprocessor-chain review, and a change to this page first. |
| GitHub, Inc. — GitHub, Actions, and Container Registry | Used for source, builds, application images, and deployment | Source, issue and account data, commit and deployment metadata, secrets, build artifacts, container images, IP addresses, and Actions logs. Recipient data is not intended. A failed health check currently can copy recent application logs into an Actions log; paths or email-failure messages can expose Recipient data. | GitHub is a United States provider with global operations and subprocessors. Repository, runner, support, administrator, log-retention, and legal-request access must be treated as possible until settings and contract evidence are captured. | The account owner, accepted terms, DPA applicability, retention settings, transfer mechanism, and security evidence are not recorded. The failure-log path is an unresolved data-minimisation and transfer gate; it must be removed or contained before production. |
| Google LLC — Sign in with Google | In use; sign-in and sign-up with Google are live on the production login page | An identity provider we offer, not one a Customer connects, so section 5 does not cover it. When a person chooses it, the OAuth exchange is browser-mediated and we receive the identity claim set the provider asserts — issuer, subject identifier, email address and its verified flag, and basic profile claims — which we use to create or match an account. It is not a Customer data feed: no Recipient data, message content or delivery data passes through it. Accounts are only created or linked when the provider asserts a verified email. | Google is a United States provider with global operations. The account, contracting entity, retention, administrative access and support position for our OAuth client are unverified. | No executed Google Cloud or Workspace data-processing terms are evidenced for this client. No adequacy or SCC coverage is claimed from Google's public documents. A person can avoid the provider entirely by using a password account. |
| Tailscale US Inc. or Tailscale Inc. — Tailscale | In use for production. The production host exists, and the tailnet is what carries operator and deployment access to it. Since 15 August 2026 the host also serves this website and the documentation site publicly, so the tailnet is no longer the only route to the machine — but it remains the only route to the application, the operator consoles and the log store | User, device, tailnet, key, connection, relay, and administrative metadata for deployment and operator access. Application traffic is intended to be end-to-end encrypted, so Tailscale is not intended to read Customer or Recipient content. | The contracting entity depends on account acceptance date and country: Tailscale publishes Tailscale US Inc. for accounts created on or after 3 September 2024 and Tailscale Inc. in Canada for specified older accounts. Our account entity, relay route, support access, retention, and settings are unverified. | The published DPA is incorporated through specified terms, but account acceptance and applicable entity have not been evidenced. No executed transfer or contract position is claimed. Production use requires an account export or invoice identifying the entity and accepted terms. |
| UptimeRobot s. r. o. — UptimeRobot | In use since 15 August 2026. Three monitors exist and two are running. They request https://saas-infrastructure.com/ and https://docs.notavia.saas-infrastructure.com/ every five minutes; a third, for https://notavia.saas-infrastructure.com/, is paused, because that address is not reachable from the public internet. All three are HTTP status monitors with no keyword or response-body matching configured, so what is read is the response status and timing and nothing else, and the addresses they request serve pages that require no sign-in. No UptimeRobot-hosted public status page exists; the service's own status page reads monitor results back through a read-only account key, which can list monitors and change nothing | A monitor, once created, requests one of our unauthenticated public URLs on a schedule and records the response status and timing. That is the whole payload: no personal data of a Customer, member, Recipient or website visitor is sent to UptimeRobot by a monitor, because an unauthenticated availability check carries no account context and no message data. In the other direction, our status page reads back only a monitor's display name and its uptime percentage. What UptimeRobot does hold is our own account data as its customer — the account users, the endpoint URLs being watched, incident timestamps and the destinations alerts are sent to. It is listed here for completeness of the vendor inventory rather than because it is a subprocessor of anyone's personal data. | The vendor is established in Slovakia. Monitor locations, account storage, support access, subprocessors, and notification routes remain unverified for our account. | An account exists and its terms are accepted. The vendor's data processing agreement requires no separate signature — it states that it is incorporated into and forms part of the agreement and binds on execution of that agreement unless a countersigned copy is requested, so accepting the terms executed it. Retention, monitor-node locations, support access and the vendor's own subprocessors remain unrecorded for our account, and this row does not treat the vendor's published security or privacy statements as audit evidence for any of them. Three changes would each stop this classification being true, and any of them must be reassessed before it ships: pointing a monitor at an authenticated endpoint; setting an alert destination to a route that carries service data; or using a keyword or response-content monitor, which captures part of the response body rather than only its status, and so can carry content off an otherwise unauthenticated URL. None of the three is in place, and the description of the live monitor in this row is written so that making any of them true is visible here. |
4. Independent Controllers
Paddle. Paddle acts as Merchant of Record and an independent controller for payment processing, fraud prevention, invoicing, tax administration, buyer support, and its legal obligations. It can receive billing-contact and organisation information, transaction and subscription details, device and network data, and payment data collected directly by Paddle. Tessora LLC does not receive full payment-card numbers.
Paddle publishes different entities by buyer location and activity. Its current supplier terms identify Paddle.com Inc. for United States buyers and Paddle.com Market Limited for buyers elsewhere; its buyer terms also identify Paddle.com (Canada) Ltd for specified Canadian transactions. Our supplier-account contracting entity, accepted agreement version, seller-verification status, production credentials, and controller-to-controller transfer terms have not been evidenced. Currency selection and billing country do not determine service data location or applicable data-protection law.
Paddle's checkout library is no longer loaded on every dashboard page. It used to sit in the dashboard's root document, so every signed-in member's browser contacted cdn.paddle.com on every page — including members who can never reach billing and will never purchase. Since 15 August 2026 it is loaded on demand, by the checkout code itself, at the moment a person opens a checkout. A member who never opens one never contacts Paddle. Paddle is not converted into a Recipient-data subprocessor by that request in either case.
5. Customer-Selected Connected Providers
When a Customer connects its own SMTP, SMS, Slack, Microsoft Teams, Discord, webhook, identity, or similar provider account, that provider acts under the Customer's agreement. The Customer selects the provider and supplies the credentials or destination. The provider is not a subprocessor selected by Tessora LLC, although Tessora LLC transmits the Customer-directed message, Recipient identifier, or event to it as part of the Customer's instructions.
Customers are responsible for the connected provider's terms, lawful use, configuration, registration, retention, and transfer position. Enabling a connection does not change the Customer's billing country, currency, or the location of data held by Tessora LLC.
Direct delivery to a Recipient, Customer-requested exports, and public DNS lookups are processing routes, not vendor engagements.
6. Operational Dependencies With No Intended Personal-Data Access
| Dependency | Use and boundary | Unresolved evidence or exit position |
|---|---|---|
| Datalust Pty Ltd — self-hosted Seq | The planned Seq instance runs on the same Hetzner host and stores logs locally. Datalust is not intended to receive those logs. Account, license, error-reporting, telemetry, and support behavior must be verified so that the boundary remains true. | No production license or settings capture exists. Disable any outbound telemetry or error reporting unless separately reviewed. Export required evidence and uninstall Seq at exit; retain or delete local logs under the service retention schedule. |
| Docker, Inc. — Docker Hub | The production compose plan pulls public PostgreSQL, Seq, Caddy, and utility images. Docker receives registry-request and account/network metadata, not application databases or Recipient content. | Pin and inventory images, retain provenance evidence, and replace the registry source if account terms, availability, or security review is unacceptable. |
| PostgreSQL and Caddy open-source distributions | PostgreSQL is the planned self-hosted database and Caddy the planned public edge. Neither project is an external hosted data processor in this deployment. | Track image provenance, versions, vulnerabilities, and replacement procedures. The full database and Caddy/host logs remain within the hosting and backup vendor scopes above. |
Removed dependencies
Recorded rather than deleted, because an inventory that only ever grows cannot show what a vendor review actually changed.
| Dependency | What it received | Removed |
|---|---|---|
jsDelivr (cdn.jsdelivr.net) and cdnjs (cdnjs.cloudflare.com) | Bootstrap and jQuery on two signed-in console pages, disclosing the IP address, user agent and requested asset URL of a signed-in member to two third parties with no agreement in place | 15 August 2026. Both libraries are served from our own origin, and the browser content-security policy that had allowed those two hosts was narrowed in the same change — an allowlist outliving the script it permitted is how the script returns unnoticed |
Cloudflare Turnstile (challenges.cloudflare.com) | IP address, TLS fingerprint, user agent, site key, origin and challenge token from every visitor to the two public form pages, whether or not they submitted anything | 15 August 2026. See the Cloudflare row in section 3 |
No external hosted log, error-monitoring, or support-ticket service is approved. Logs are intended to remain in self-hosted Seq. The provider of the inbound support and privacy mailbox has not been identified, and the operator alert provider is unselected; neither may be represented as approved or receive production personal data until entered in the vendor register.
7. Change Notice and Objections
Before authorising a new or replacement Recipient-data subprocessor to receive production data, Tessora LLC will:
- complete the role, data, location, access, security, contract, subprocessor-chain, retention, deletion, incident, government-request, transfer, and exit review;
- publish a new version of this schedule without overwriting the prior version;
- link the applicable schedule version immutably to the organisation's DPA and transfer-term acceptance record; and
- give at least 14 days' advance notice to each affected organisation's Owners and Administrators.
The notice will identify the vendor, legal entity, role, product, purpose, data, country or region, intended activation date, transfer position, updated schedule version, and objection route. An affected organisation may object on reasonable data-protection grounds during the notice period. We will assess the objection, document the decision, and where reasonably available offer an alternative or restrict the affected service. If no reasonable resolution exists, either party may terminate the affected service under the DPA and the termination-to-deletion process will apply. Where the organisation terminates for that reason, DPA section 7.2 gives it a pro-rata refund of the prepaid fees for the unused remainder of the current billing period.
Those four steps are carried out by the application, not by hand. A subprocessor change is opened as a record; the notice is issued to each affected organisation's Owners and Administrators and each recipient's delivery is recorded individually; an objection can be recorded against the change and must be given a recorded decision; the schedule version is published as an immutable snapshot; and the accepted snapshot is linked to the organisation's acceptance record so that a later change to this page cannot alter what an organisation agreed to. An activation gate then evaluates the change and refuses to let it activate while any affected organisation is unclear. Three of that gate's rules are worth stating, because they decide the cases that would otherwise be decided by whoever was in a hurry: silence is not an objection, so a delivered notice that nobody answered clears once the 14 days elapse; a failed delivery never becomes consent, so an organisation whose notice the transport did not accept blocks activation however long ago it was issued; and an organisation for which no recipient was recorded counts as not notified, not as notified with nobody to tell. The 14 days run from the last recipient reached, not the first, because that is the person who has had the least time to object. An operator console shows every change, its notices and its objections.
Two limits are real and are not softened by any of that. The vendor review in step 1 is a judgement made by the accountable operations role, not something the application performs. And none of this has ever run against a real customer, because there has never been one — so it is evidenced as built and tested, not as exercised. Emergency handling does not silently waive the 14-day promise; production data must be isolated, service restricted, or organisation-specific agreement obtained unless the accepted contract provides another lawful path.
Account and site-data processors and independent controllers are reviewed under the same intake process. They receive the contractual subprocessor notice where their actual role or data access makes that necessary, and otherwise receive any material privacy or contract notice required for their role.
8. Contact
For vendor questions, change notices, or objections, contact support@saas-infrastructure.com.
Tessora LLC
Incorporated under the laws of the State of Wyoming, United States.
Registered office and mailing address: 30 N Gould St Ste N, Sheridan, WY 82801 US.