By David,
People searching for "self-hosted email signature management" are usually not in love with hosting things. They're expressing a constraint: our directory data and our mail can't live in someone else's cloud. Self-hosting is the only vocabulary the market has offered for that constraint - so that's the word they search, and then they discover the actual self-hosted options and their enthusiasm dims.
Let's take the constraint seriously, map the two traditional answers honestly, and then name the third model the binary leaves out.
What SaaS actually costs
The hosted platforms - CodeTwo, Exclaimer, Crossware, Opensense, and the rest - are mature, capable products, and the SaaS model is why: fast onboarding, zero servers, continuous features. The costs are structural rather than visible:
- Your data moves. Directory attributes sync into the vendor's database so templates can render; with the mail-flow products, outbound messages transit the vendor's service to be stamped. Both are exactly what a residency or privacy review exists to flag - here's the full tracing exercise.
- Your review scales with their surface. A multi-tenant platform holding many customers' directory data is a shared blast radius. Assessing it properly is real work, renewed every year, and you can't shrink it - only document it.
- The subscription never ends. Per-seat pricing across your licensed headcount, campaigns or not, usage or not, with an annual commitment if you want the good rate.
What self-hosting actually costs
The genuinely self-hosted end of this market is thin - mostly Exchange transport-rule setups managed by hand, PowerShell scripts writing signatures from Graph data, or on-premises tooling from a previous era. If you go this way, you own everything: the code or config, the patching, the token-hydration logic, the edge cases (shared mailboxes, litigation holds, hyphenated names that break layouts), the monitoring, and the bus factor when the script's author leaves.
The honest summary: self-hosting buys you data control at the price of becoming a small product team. Some organizations genuinely should pay it. Most who start down this road are paying for the constraint - data stays home - while accumulating an unbudgeted engineering liability to get it.
The third model: customer-owned deployment
Here's the option the binary hides: the product deploys into your cloud subscription. Not the vendor's cloud with your name on a tenant, and not a tarball you operate - a managed product whose entire runtime lands inside your own Azure subscription.
That's Atlas Ink's model, concretely:
- Deployment: installed into your own subscription - your App Service, your per-tenant PostgreSQL database, your Key Vault keys.
- Data: templates and assignments at rest in your tenant; Entra ID read in place, read-only; no vendor database anywhere holding your people. The only thing that leaves is the monthly active-user count, reported to Atlas for metered billing via Stripe.
- Mail: never routed through Atlas. By default Atlas pushes each user's Outlook compose signature via the Exchange admin API - no transport rules, no stamping, no interception. Optional server-side stamping, which an admin turns on explicitly, adds one mail-flow rule in your own Exchange Online - never a vendor hop.
- Operations: you do standard Azure resource hygiene - the tagging, monitoring, and access reviews your subscription already enforces - not software maintenance. Product updates come from the product; you don't patch a signature server at midnight.
- Pricing: metered at $1 per active user, per month, always - no seats, no annual commitment, plus the (small) Azure infrastructure cost you pay Azure directly, at cost, on your own invoice.
The three models, side by side
| SaaS platform | True self-hosted / DIY | Customer-owned deployment | |
|---|---|---|---|
| Where your data lives | Vendor's environment | Your infrastructure | Your subscription |
| Who operates the software | Vendor | You | Product-managed, in your tenant |
| Mail path involvement | Often (stamping architectures) | Your choice | None by default - mailbox push |
| Security review scope | Vendor environment + data flows | Your build | Your existing Azure boundary |
| Engineering burden | None | The whole product | Azure resource hygiene |
| Cost shape | Per-seat subscription | Hidden engineering time | Metered per active user + small infra |
| Exit | Offboarding request + trust | Turn it off | Delete the resource group |
How to choose
If the data constraint isn't real for you - no residency requirement, no mail-path sensitivity - the SaaS field is mature, and the buying guide will sort it quickly. If your organization already runs internal products with real engineering ownership, DIY is legitimate; cost it as a product, not a script.
But if you searched "self-hosted" because the data must stay home and you'd rather not staff a signature engineering function - the third model is the one you were looking for. Own the subscription, the database, the keys, and the boundary; let the product be a product. That's Atlas Ink, and the deeper dive on what ownership changes is here.