Infrastructure

Sigil runs on Cloudflare’s network, pinned to Cloudflare’s Western Europe region so that every signature request is handled next to Sigil’s databases and close to the Microsoft directories it reads from. A fixed region keeps the database and directory calls behind every compose short and predictable.

The stores that hold your data are created in Cloudflare’s EU jurisdiction, which is a limit Cloudflare enforces rather than a location it prefers. Since 27 October 2026 that includes the caches in front of them. What can still leave the EU is the short-lived read copy Cloudflare keeps close to whoever reads a cached entry, which is what lets a signature arrive quickly wherever it is composed. See where data lives.

Components

Component	Used for
Cloudflare edge compute	The API, the admin portal and the redirect service
Cloudflare D1	The shared database: organisation records, billing state, API key hashes, tracked link destinations, portal sign-ins, the names shown against portal users and partner records, which Sigil has to read before it knows which organisation a request belongs to. In Cloudflare’s EU jurisdiction
Cloudflare Durable Objects	Each organisation’s own database, holding its templates, configuration, telemetry and change log. Also the portal’s live updates: the open connections, and the list of recent changes a page catches up from. All in Cloudflare’s EU jurisdiction
Cloudflare R2	Uploaded images, preview pictures and nightly database backups, all in Cloudflare’s EU jurisdiction
Cloudflare KV	Rendered signature cache, directory lookups, profile photos and per-mailbox rule resolution. Stored in Cloudflare’s EU jurisdiction, with read copies cached on the global network, and all expiring on their own
Cloudflare’s headless browser	Rendering the signature previews shown in the portal and in Sigil’s emails
Cloudflare Email	Invitations, test emails, approval requests, the health digest, billing and trial notices, product updates and service notices
Cloudflare AI Search	Answering questions typed into Ask the documentation. Nothing is kept
Stripe	Subscriptions, payment methods and invoices
Microsoft Entra ID	Authentication for both the add-in and the portal
Microsoft Graph	Read-only directory attributes for personalisation

Hostnames

Host	Serves
portal.usesigil.app	Admin portal, designer, and the signature API
static.usesigil.app	The add-in bundle and its manifest
e-clk.usesigil.app	Tracked link redirects only

The add-in is served from a different hostname to the API on purpose, so the code your users’ Outlook loads is kept apart from the service it calls.

The link domain answers /r/ redirects, contact card downloads and the /.well-known/ path a certificate authority uses to check domain ownership, and returns 404 for everything else, so the surface that recipients touch carries no portal or API.

An organisation holding the branded link domain add-on has a fourth host, its own, serving its tracked links in place of e-clk.usesigil.app. It is a hostname on the customer’s domain pointed at Sigil by a CNAME. It is not narrowed to redirects in the same way, but the portal and the API still need a signed-in session there. Only redirects, contact cards and Sigil’s public information pages, such as the privacy policy and terms, answer without one.

Code loaded from other hosts

The components above are the services Sigil runs on. Two further hosts are reached by the Outlook client rather than by Sigil’s servers, and they are worth stating plainly because they serve the only code inside your users’ Outlook that Sigil did not write. Both are Microsoft’s.

Host	What it serves	Reached by
appsforoffice.microsoft.com	Office.js	The add-in, on every path
ajax.aspnetcdn.com	MicrosoftAjax.js, part of the same runtime	Microsoft’s runtime, on Outlook for Mac, iOS and Android, and sometimes on Windows

Office.js is not optional and not a choice Sigil made. Microsoft requires every Office add-in to load it from that host, and an add-in that bundled its own copy would not run.

The second host is one step further removed. Sigil’s pages name one script origin, and it is the first. Nothing Sigil wrote points at ajax.aspnetcdn.com: the Office.js runtime fetches MicrosoftAjax.js from there itself, always on Mac, iOS and Android, and on Windows when the Outlook build asks for it. Outlook on the web takes its copy from appsforoffice.microsoft.com and never reaches the second host at all. The add-in’s content security policy names both hosts, so a script from anywhere else would be refused. See what the add-in needs to reach for what a network that blocks it would see.

Neither host is a third party, and that is the property worth holding. The icons in the “My signature” pane were once drawn by a script fetched from unpkg.com, which put a third party in a position to run code in the origin that holds the sign-in client and the Office.js bridge, in order to draw seven glyphs. Those glyphs are now shape data inside the add-in’s own bundle, so the pane loads no script but Microsoft’s. A check on every build fails the release if a third-party script reference reappears on either add-in page, which is what keeps this a property of the add-in rather than a fact that happens to be true today.

The typefaces the pane and the admin portal are set in are deliberately not on this list either. They are served from Sigil’s own hosts rather than from Google Fonts, so opening the pane or the portal discloses nothing to a font provider, not even an IP address.

Microsoft is sent nothing of yours. Each host answers a request for a script, and what it learns is what any web request discloses: the address it came from and the page that made it. Signature content, directory attributes and tokens never travel to either.

The network view of the same list, written for an administrator configuring an outbound filter, is on requirements.

Caching

Rendered signatures are cached in KV, keyed by template id, template version and email address. The banner and footer in force are part of that key, and so is a counter that moves whenever an image is uploaded or replaced, which is what keeps a swapped logo instant now that the cached entry holds the image bytes alongside the HTML.

Publishing a template increments its version, which strands every cached entry for it at once. That is why edits reach users in seconds without an explicit purge.

A one hour freshness window sits on top of that, which is how a change to somebody’s job title in Entra reaches Outlook without anyone republishing: a cached entry older than the window still serves that compose, then re-renders in the background from a fresh directory read, so the change lands on the compose after. The entry itself lives a day, though a nightly pass renders a fresh one for every mailbox that composed in the past week, so Monday’s first message is as quick as Friday’s. The attributes are read when a signature is rendered and are never stored as a record of their own: the rendered signature, the directory lookup below and the profile photo cache are the only places they sit on the server, apart from short-lived results behind the portal’s people picker and the group memberships that assignment rules and cost management work from. The add-in also keeps a copy of the last signature it applied on the device, described in data and privacy.

The answer to a directory lookup counts as fresh for fifteen minutes, so that a person composing several messages is not looked up in Graph each time. After that it still answers straight away while a fresh copy is read in the background, and it is kept for seven days after it was last read from Graph, so the first message of the morning is not held up by a slow Graph call. The nightly pass above reads Graph again for every mailbox that composed in the past week, so directory data for a mailbox can remain for up to about two weeks after its last compose. That, not the day above, is what bounds how long directory data exists inside Sigil. A deprovisioned organisation has it cleared with everything else.

The routing decision behind assignment rules is cached separately, keyed by a rules version that changes whenever the rules are edited, so an edit strands every cached decision at once. An hour-long freshness window sits on those entries as well, after which the decision is re-checked against the directory in the background rather than while somebody is composing. That is what bounds how long a directory attribute can go on routing somebody to a template they should no longer be getting: an hour, and then one further message.

Reliability characteristics

Telemetry writes are best-effort and off the critical path. A storage problem loses a telemetry record rather than delaying or failing the signature somebody is waiting on.

The directory cross-reference in the Activity view is also best-effort. If Graph is briefly unavailable, the rest of the telemetry still renders.

The add-in’s outcome beacon is time-boxed and never holds a compose window open.

An interruption to Sigil affects signature management rather than mail flow. Sigil never gates the sending of email, so an outage costs you the portal and the application of signatures, not your users’ ability to send.

Availability commitment

There are two answers, depending on how you buy Sigil.

Bought directly, there is no contractual uptime figure. The terms of use aim at a reliable service without guaranteeing uninterrupted availability, and the support page states an aim of a response within one business day.

Bought through a managed service provider, the partner agreement commits to 99.9% monthly uptime with a service credit table behind it, and a four business hour response target on escalations. That commitment runs between Tophhie Cloud and the provider, so what reaches you is whatever your provider has agreed with you on the back of it. See support and service level.

Either way, the current state of the service is published on the status page.

The status page

status.usesigil.app is the public status page. It carries the current state of Sigil and any incident that is open, and it is where to look first when signatures have stopped across an organisation for no reason you can find.

It is hosted away from Sigil deliberately. A status page served by the thing it reports on is worth nothing during the one event it exists for, so the page is run by a third party on infrastructure Sigil does not share.

What sits behind it is an external monitor that renders a signature end to end from more than one region, every few minutes, and treats the result as a failure unless a valid signature came out. A check that only asked whether the service answered would report a service returning errors as healthy.

A failure has to be confirmed from a second region before an incident is opened, so one region’s network trouble is not reported as an outage of Sigil.

A second monitor checks that the platform underneath is answering at all. The two together are what separates a fault at Cloudflare from a fault in Sigil, which matters because the partner service level excludes the first and not the second.

The status pill in the portal

You do not have to go and look. Every page of the portal carries a status pill beside the page title, and the public support page carries the same one for somebody who cannot sign in. It reduces the state of Sigil to one of three answers and links to the full page.

The pill claims nothing it cannot stand behind. If the status page cannot be read, it shows no colour and no wording beyond “Service status”, because a pill saying all is well because it could not reach the status page would be worse than no pill at all.

Your browser never contacts the status host. The portal reads the page on your behalf and caches the answer for a minute, so however many people have the portal open it is one read, and no visitor of yours is disclosed to the company hosting the status page. The pill refreshes every five minutes while you leave the portal open.

Two things the page does not carry, deliberately. There is no historical uptime percentage on it, since a figure published before it has been measured for long enough invites more questions than it settles. And the heartbeats behind Sigil’s own overnight jobs are not on it either: whether a nightly rollup ran is an operational matter rather than something to report as an outage.

Health

portal.usesigil.app/health reports configuration and storage state. It is a service-level check rather than a per-tenant one.