EU Hosting & Data Residency
Paminga runs a second, complete production stack in AWS Frankfurt, Germany (eu-central-1). If your organization needs its marketing automation data to live in the EU, we provision your account there instead of in the United States.
It's the same platform either way — same features, same release schedule, same documentation, same support team. What changes is where your data sits and which infrastructure processes it.
Hosting region isn't a setting you'll find in the platform. It's chosen at provisioning time and stays fixed for the life of the account, because it determines which databases, which object storage, and which email infrastructure your account lives on. Tell us during onboarding that you need EU hosting and we'll provision you there.
Where Your Data Lives
Everything that makes up your account sits in eu-central-1:
- Contacts, accounts, and activity history — the primary databases holding your records
- Digital assets — images, PDFs, video, form file uploads, and your published landing pages
- Cache and queue infrastructure — the working state behind segmentation, automations, and email sends
- The application itself — the API, background workers, schedulers, and the email and landing page renderers
That last point is worth calling out. This isn't a US application reading from an EU database. The compute that processes your data runs in Frankfurt alongside it.
A few things do reach systems outside the EU, AI features chief among them — see What Still Involves Systems Outside the EU below.
A Separate AWS Account, Not a Shared Environment
For anyone running a security review, this is usually the question underneath the question: how separate is "EU hosting", really?
The EU stack lives in its own AWS account, with its own VPC, its own databases, its own object storage, its own secrets, and its own credentials. There is no replication between the US and EU stacks. The one connection between them is an authenticated, encrypted channel that Paminga's own systems use to administer EU accounts (provisioning, suspension, support sign-in) and to carry the usage events described below. Your contacts, accounts, and activity history never travel over it, and no US database holds them.
Databases sit in private subnets with no route in from the public internet. Application traffic reaches them only from inside the EU VPC.
Your EU Hostnames
EU accounts use a distinct set of hostnames. If your IT team maintains an allowlist, these are the ones to add:
| Host | Purpose |
|---|---|
app.eu.paminga.com | Where your team logs in |
api.eu.paminga.com | The GraphQL API and integration OAuth callbacks |
apps.eu.paminga.com | Tracking beacon and email engagement endpoints |
crm.eu.paminga.com | Where the CRM panel loads from inside Salesforce and Dynamics 365 |
eu.result.ma | Default domain for shortened links |
Email Delivery from the EU
Paminga sends EU accounts' email through SendGrid's EU region. Your account's sending identity is pinned to that region, so sends, open and click tracking, suppression handling, and link branding all run against EU infrastructure rather than routing back through the US.
Link shortening runs on EU infrastructure too. Shortened links mint under eu.result.ma unless you set up your own branded short domain.
The DNS work on your side is identical to a US account — the records simply point at EU hosts. See Email Delivery for the setup steps.
Integrations Run from the EU Too
When an EU account connects Salesforce, Dynamics 365, Google Ads, or Zoom, every part of that connection that belongs to Paminga runs in the EU. The authorization flow returns to api.eu.paminga.com, the credentials it produces are stored in the EU, and the sync workers that read and write on your behalf are EU workers. Your CRM data does not detour through the United States on its way in or out.
Where a provider offers a regional endpoint, we use the EU one. That's why your account's email goes through SendGrid's EU host rather than its global one. Where a provider doesn't offer one, we say so — see AI Features below.
What Paminga can't set on your behalf is where your own systems live. Which region hosts your Salesforce org or your Dynamics tenant is determined by your contract with that provider, not by us. If you need EU residency end to end, that's the piece worth confirming on their side — but apart from the items under What Still Involves Systems Outside the EU, nothing about how Paminga is hosted pushes your data outward.
Encryption
In transit: every public endpoint enforces HTTPS with a TLS 1.2 minimum. Internal cache and queue traffic is encrypted in transit as well.
At rest: all database and application volumes are encrypted, object storage uses server-side encryption, and the cache tier is encrypted at rest.
Logging Stays in the EU
Application logs are, by their nature, the most personal-data-dense thing an operations team touches — they can carry email addresses, names, and IP addresses in plain text.
EU application logs are written to a log host inside eu-central-1, with capped retention, and are never forwarded to our US logging infrastructure. Network policy blocks that path independently of configuration.
Error reports are the exception. When the application hits an error, a report goes to our error-monitoring service, which is hosted in the US — see Error Monitoring below.
We also deliberately don't collect CDN or web application firewall access logs in the EU. Those logs are IP-address-bearing by design, and we'd rather not hold them than hold them well.
The firewall itself still runs: AWS managed rule sets sit in front of both the application load balancer and the CDN edge, blocking common injection, bad-input, and reputation-based attack traffic.
Backups
Database backups are encrypted snapshots taken in-region. They're captured from dedicated database replicas rather than the primaries, so backups never require taking your account offline. Backup data does not cross international borders.
What's Identical to a US Account
Feature parity is the point. EU accounts get the same builders, the same automations, the same reporting, the same integrations, and the same account setup process — the DNS records just point at EU hosts.
Every page in these docs applies to your account. Where a screenshot shows an app.paminga.com URL, read it as app.eu.paminga.com.
What Still Involves Systems Outside the EU
Five things, and each is worth understanding precisely.
Content Delivery
Your published landing pages, hosted images and files, and the tracking beacon script are served through a global CDN (Content Delivery Network, Amazon CloudFront), which caches them at edge locations near your visitors. That's delivery of the marketing content you've chosen to publish publicly. Your contact records, activity history, and account data are not part of it.
AI Features
Paminga's AI features run on Anthropic's Claude models, and Anthropic publishes a single global API endpoint. There is no EU one to point at — unlike SendGrid, where an EU host exists and we use it. So when an AI feature runs, the material it works from is processed outside the EU, regardless of where your account is hosted.
That material is whatever the feature needs to do its job: the account or contact record in front of it, the fields you've asked it to populate, the page text it crawled, the asset you're building. The result comes back into your EU account and is stored there like everything else.
This applies whenever an AI feature runs, not only to the ones you trigger by hand. An automation you've configured — an action that classifies an account or fills in fields on your behalf — reaches the same models the same way.
Anthropic is named on our sub-processor list and is bound by the same written security and data-protection commitments we require of every sub-processor. Under Anthropic's commercial terms, your content is not used to train their models.
If EU-only processing of that material is a hard requirement for you, it's worth raising with us before you build automations that depend on AI features.
Error Monitoring
When Paminga's application hits an error, it sends a report to Sentry, our error-monitoring service, which is hosted in the United States. EU accounts report to the same service.
A report exists to tell our engineers what broke and where: the error, the code path, and the request or background job that triggered it. None of that needs your data, so a report from our servers has it masked before it's sent. Values from the record being saved, the request, and the code that was running are replaced with [Filtered] unless they're an ID, a date, or a status code, and email addresses are masked wherever they appear. Our engineers look the problem up from the IDs that are left.
A report from your browser identifies the signed-in user by ID only, never by name or email address. It can also include a recording of the session leading up to the error. All text and everything typed is masked in that recording, and photos and video are blocked, so it shows the page's layout and where you clicked rather than what was on the page. The exception is a design open in one of the builders: some of its images can show as they are, though its text is still masked. Sentry is set not to store IP addresses.
The masking is automatic and errs toward removing too much, but no automatic filter can promise that nothing personal ever gets through. A browser report, for instance, carries the error message exactly as the page received it. That's why we treat Sentry as a sub-processor.
Mobile Push Notifications
If you use the Paminga mobile app, its alerts reach your phone through Apple's Push Notification service, which Apple runs globally. An alert's text comes from the notification it announces, so it can include details from your account. Apple delivers the alert; the account data behind it stays in the EU.
Alerts go only to phones that are signed in to the app. Signing out, or removing the phone from your signed-in devices, stops them. A phone that had the app deleted without signing out first stays registered until Apple turns away the next alert sent to it. If nobody on your account is signed in to the mobile app, nothing goes this way.
Sentry and Apple are both named on our sub-processor list.
How Your Team Uses Paminga
Paminga's own marketing and customer-success records live in our US account. When people on your account use Paminga — signing in, creating an email or form, activating a workflow, connecting a CRM, importing contacts — that activity is recorded there against the user's name and email address, so our team can see how onboarding is going and where to help.
These events are about your team's use of Paminga. They carry no contacts, accounts, activity history, or content from your account.
Compliance Documentation
Paminga maintains a SOC 2 Type II report and ISO 27001 certification covering our information security program. Both are available on request under mutual NDA.
Our Data Processing Addendum sets out how Paminga processes personal data on your behalf, including how to object to a sub-processor.
Our sub-processor list names the third parties Paminga engages to process personal data on your behalf, and where each is located. Systems you connect through an integration aren't on that list — those are your own systems, receiving data at your instruction. You can subscribe to be notified whenever the list changes.
EU hosting addresses where your data lives. It's one input to GDPR compliance, not all of it — consent capture, opt-out handling, and data erasure are still program decisions you make. See GDPR for how Paminga's consent features support that work.
Getting an EU Account
Tell us during onboarding, or reach out to support@paminga.com and we'll route you to the right person. If you already run a US account and need to move to the EU, start with your Customer Success rep — see Support for how to reach them.
