Why a self-hosted PagerDuty alternative for EU data residency needs a closer look
If your on-call data must stay in the EU, running GoAlert inside your own EU infrastructure is the self-hosted option that addresses the constraint, and the main caveat is the notification path, because GoAlert sends SMS and voice through Twilio, which processes those messages on its own systems. Moving a PagerDuty account to its EU region is not a simple switch: the region is fixed at sign-up, so the practical choices are a paid migration or a rebuilt account that loses incident history. Either way, the question for your team is where the paging data lives and who can reach it, not only where the vendor's headquarters sits.
The GDPR treats any transfer of personal data to a third country as a restricted act. Under Article 44, every transfer, including onward transfers, must meet the Chapter V conditions, and infringements of Articles 44 to 49 can draw fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c). The EDPB's Guidelines 05/2021 make the scope wider than storage alone: remote access from a third country, even only displaying data on a screen for support, counts as a transfer, and so does storage in a cloud outside the EEA. A rota stored in an EU region can still be exposed if support staff abroad can view it.
That is why the deployment model matters as much as the region label. With GoAlert, your team controls the PostgreSQL database, the data encryption key and the access paths, so you can decide which personnel and locations reach the system. Before you commit, confirm with any vendor where its support staff access data from, where backups and logs are kept, and how it would respond to a request from a non-EU authority. Then document the Twilio path separately, since SMS and voice content and phone numbers leave your infrastructure whenever a page is sent.
What EU data residency requires of a paging system
A paging system holds personnel contact details, rota data and incident context, so each component that stores or touches that data falls under the same transfer analysis. The cards below set out the EU rules that decide where that data may sit, who may reach it and which vendors create exposure.
Transfers under Chapter V
Article 44 of the GDPR requires every transfer of personal data to a third country, including onward transfers, to meet the conditions of Chapter V. For a paging system, on-call rosters, phone numbers and incident notes are personal data, so any hosted component that stores them outside the EEA needs a documented transfer basis. Ask each vendor where its paging data is stored and where its sub-processors sit.
Fines for Articles 44 to 49
Infringements of Articles 44 to 49 fall under the higher fine tier in Article 83(5)(c), up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. A transfer problem in the paging stack is therefore not a minor record-keeping issue. Treat the notification path as a regulated data flow when you assess vendors and write the processing record.
Remote access counts as transfer
EDPB Guidelines 05/2021 state that remote access from a third country is a transfer, even when data is only displayed on a screen for support or administration. Vendor engineers in another country who troubleshoot your paging tenant can therefore create a transfer. Ask for support access controls, where administrators sign in and whether support sessions can be restricted to EEA staff.
Schrems II and the Data Privacy Framework
The Court of Justice invalidated the Privacy Shield in Case C-311/18 (Schrems II) on 16 July 2020, while holding that standard contractual clauses remained valid. Adequacy for US organizations now depends on the Data Privacy Framework List under Decision (EU) 2023/1795, and an appeal against the General Court's judgment upholding it is pending as Case C-703/25 P. Check whether a US-based vendor is on the list and whether your contract also carries standard contractual clauses as a fallback.
CLOUD Act exposure
The US CLOUD Act provision at 18 U.S.C. 2713 requires communication and remote computing providers to preserve or disclose data in their possession, custody or control, wherever that data is located. An EU region of a US-controlled SaaS paging product can still fall within that reach. Under GDPR Article 48, a foreign disclosure order is recognized only if it rests on an international agreement, so ask counsel to assess this exposure before you engage the provider.
Where PagerDuty's EU region fits and where it does not
If your incident data already sits in PagerDuty's US region and your obligations allow it, staying put avoids migration work and keeps incident history intact. The region is fixed at sign-up, so the practical question is whether the transfer position for that account is documented and current. Under GDPR Article 44, every transfer of personal data to a third country must meet Chapter V conditions, and EDPB Guidelines 05/2021 treat remote access from a third country as a transfer, even when data is only displayed on a screen.
- Contract and transfer records: Keep the processing terms, the transfer mechanism and your transfer assessment for the US account on file, and check them against current data flows.
- Support access: Ask where PagerDuty support staff access data from, since remote viewing from outside the EEA falls under the EDPB guidance.
- Data Privacy Framework status: Confirm whether PagerDuty relies on the EU-US Data Privacy Framework, because the adequacy decision is under appeal as Case C-703/25 P.
- Exit options: Staying in the US region still keeps switching open. The Data Act gives customers switching rights from 12 September 2025, and you should confirm whether they apply to your PagerDuty contract.
Confirm in writing the hosting region for each PagerDuty component, the subprocessors that touch incident data and how Twilio notifications are routed.
Moving to the EU region is a migration project with a cost, and it does not automatically change the legal position of data already processed in the US. The topic scope notes that a move is a paid migration, so the fee and the exact scope come from PagerDuty's written quote. Before agreeing to it, you need to know which records are carried over, which are left behind and how paging continues during the switch.
- Migration scope: Ask which data moves, including incidents, services, schedules, escalation policies, users and audit logs, and which items are excluded.
- Cutover plan: Ask whether both regions can run in parallel and how on-call notifications continue during the switch.
- Residual copies: Data processed in the US may persist in backups, logs or subprocessor systems. Ask for written deletion confirmation and the timeline PagerDuty will commit to.
- Integrations: Monitoring integrations and API endpoints may change. Plan the re-pointing work and test it before cutover.
- Contract terms: Obtain the new processing terms and subprocessor list before signing, and compare them with your current ones.
Get the migration scope, deletion commitments and the EU subprocessor list in writing before you commit to a date.
A rebuilt account in the EU region starts clean. That satisfies residency for new data, but incident history, responder records and postmortem context do not carry over unless you export them first. Illustrative example: a team rebuilds its on-call schedules and escalation policies in a new EU account but cannot show who responded to last year's database outage during its review, because that record stayed in the old account.
- Loss of history: Incident timelines, notes and responder records do not carry over automatically, so export them before closing the old account.
- Audit evidence: Compliance reviews that ask for past incident response need that archive held in storage you control.
- Rebuilt identities: Users, schedules and rotations must be recreated and verified, which often surfaces gaps during the first on-call cycle.
- Old account retention: Confirm what PagerDuty keeps after closure, where it is held and when US-held data is deleted.
- Rebuild effort: The work scales with the number of services, rotations and integrations, so build the effort estimate from your own inventory.
Ask PagerDuty for the export format and a written deletion confirmation for the closed account before you start the rebuild.
Running GoAlert inside your own EU infrastructure places the paging system under your control. GoAlert is licensed under Apache 2.0, ships as a single binary and needs PostgreSQL as its only hard requirement. Data stays in the database and cloud accounts you choose, but notification delivery still depends on Twilio, which is currently the only supported provider for GoAlert voice and SMS.
- Hosting location: Run the GoAlert instances and the PostgreSQL database in the EU accounts or data centers you select.
- PostgreSQL setup: Use PostgreSQL 17 or newer with the pgcrypto extension, in the same region as the application.
- Encryption key: Set a data encryption key so sensitive values such as API keys are encrypted before being written, and use the same key on every instance.
- Twilio processing: Phone numbers and message content reach Twilio. Confirm its processing regions, subprocessors and transfer terms in writing before you choose the deployment.
- Login and identity: GitHub OAuth or any OpenID Connect provider can handle sign-in, with Dex suggested to bridge other identity systems.
Confirm the Twilio account region, message routing and subprocessor terms first, because they decide where paging data is processed even when GoAlert runs in the EU.
An EU region narrows where data is stored but does not remove exposure to foreign legal orders. Under 18 U.S.C. 2713, electronic communication and remote computing service providers must preserve or disclose data in their possession, custody or control whether it is inside or outside the United States. EDPB Recommendations 01/2020 state that where a provider must access data in the clear and a third country's powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure.
- Control versus location: A US provider holding data in an EU region can still be subject to the CLOUD Act for that data.
- Recognition of orders: Under GDPR Article 48, a third-country disclosure order is recognized only if it rests on an international agreement in force with the Union or a Member State.
- Penalties: Infringements of the transfer articles carry fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c).
- Self-hosting narrows exposure: Running GoAlert yourself keeps the paging data under your control, though Twilio remains a third party for voice and SMS.
- Documented assessment: Record the transfer and access analysis for each provider in the chain, including Twilio.
Ask PagerDuty and Twilio whether they can be compelled to produce data they hold, how they would respond to such a request and what they will commit to contractually.
How GoAlert keeps on-call data inside your own EU infrastructure
Residency is decided by where you deploy GoAlert and who can reach its data, not by the software itself. GoAlert ships as a single binary and as Docker images published for each release under goalert/goalert, so it can run in your own EU cloud account, an EU data centre or a network you control. The only hard requirement is a PostgreSQL database, and the getting started guide recommends PostgreSQL 17 or newer for new installations and requires the pgcrypto extension. Confirm that the database, its backups, replicas and log storage all sit in the EU region you choose, because on-call records such as users, schedules, escalation policies and incident history are written there. The Twilio piece is separate: Twilio is currently the only supported provider for voice and SMS, so message and call content and phone numbers leave your infrastructure for Twilio's processing. Confirm Twilio's processing locations and contract terms before you commit to an EU residency claim.
GoAlert recommends setting a data encryption key so sensitive values such as API keys are encrypted before they are written to the database, and the same key must be present on every instance. Store that key in your secrets manager, restrict who can read it, and plan for its rotation and recovery, because losing it leaves encrypted values unreadable. For high availability, the getting started guide recommends running one instance in the default engine mode and the rest with the --api-only flag, for example in a Kubernetes cluster, and it supports database switchover with minimal disruption. Keep every instance, including the API-only ones, in the same EU boundary, and check that load balancers, logging and monitoring you add around them do not export paging data elsewhere.
Administrative access decides who can see on-call data, so define it before go-live. Anyone with database, container, cluster or backup access can read personal data even when the application is correctly located, and EDPB Guidelines 05/2021 treat remote access from a third country, including viewing data on a screen for support, as a transfer. Write down which staff, vendors and support engineers hold each role, and confirm where they connect from. Pick an identity provider for GoAlert login, either GitHub OAuth or an OpenID Connect provider with Dex as a bridge, and review that choice for the same residency question. Your legal team should also assess whether the cloud provider or any operator is subject to third-country law with extraterritorial reach, since that affects the risk of government access even inside an EU region.
Which self-hosted options meet an EU residency requirement
This table compares three paths for keeping paging data in the EU: PagerDuty's EU region, a rebuilt EU account, and GoAlert run in your own EU infrastructure with Twilio for SMS and voice. Read each row for where data is stored, where notifications are processed and what you must verify. The table does not establish compliance, since residency and transfer obligations depend on your own assessment.
| Option | Where incident and schedule data sits | Where notifications are processed | Licensing and trade-offs |
|---|---|---|---|
| PagerDuty EU region | Region is set at sign-up. Moving an existing US account to the EU usually means a paid migration, so confirm the current process with PagerDuty. | Sub-processors and carrier paths are PagerDuty's to name. Request the current list and processing locations in writing. | Proprietary SaaS. Residency rests on a vendor commitment you verify in contract. Confirm current plan and add-on packaging. |
| Rebuilt PagerDuty account in the EU | New tenant in the EU region. Incident history stays in the old account, so export what you need before cutover. | Same provider and sub-processor chain as the EU region option. Verify it separately for the new account. | Same proprietary licensing. Main trade-offs are lost incident history for audit trails and reconfigured integrations. |
| GoAlert in your EU infrastructure | Stored in your PostgreSQL database on EU hosts you choose. PostgreSQL 17 or newer is recommended, with the pgcrypto extension. | Slack and email paths stay in your environment. SMS and voice go to Twilio, the only supported provider today. | Apache 2.0, single binary. No AIOps, status pages or runbook automation. You operate the database and paging path. |
| Twilio path for GoAlert | Phone numbers and message content reach Twilio. Confirm which fields are sent and how long Twilio retains them. | Ask Twilio for processing regions, sub-processors and the transfer mechanism covering any processing outside the EEA. | Twilio's terms govern this path, not GoAlert's license. Record Twilio as a separate processor in your register. |
| Support and admin access (all options) | Remote access from outside the EEA, including viewing a screen, can count as a transfer under EDPB guidance. | Limit administrator and vendor access to EEA locations, or document the transfer basis for any exception. | Applies to every option. Your DPO or counsel makes the determination, not the software vendor or DeployOpen. |
How to deploy GoAlert inside EU infrastructure
This sequence produces a GoAlert deployment whose database, application instances, identity connection and notification path sit where your EU residency assessment says they should, with paging proven before any real incident depends on it.
Confirm EU hosting location and access model
Your architecture or compliance lead records which EU region and data centers will host the GoAlert instances and PostgreSQL database, and who in the organization and at any vendor can reach them, including support staff in third countries. Document whether administrators access the systems remotely from outside the EEA, because EDPB Guidelines 05/2021 treat remote access from a third country, even just viewing data, as a transfer. The step is done when the hosting location, operator list and access paths are written down and approved.
Provision PostgreSQL 17 with pgcrypto
Your platform team creates a PostgreSQL database in the approved EU location, using PostgreSQL 17 or newer for a new installation, and enables the pgcrypto extension that GoAlert requires. Keep the database on infrastructure you control, with encrypted storage, network restrictions and backups held in the same jurisdiction. The step is done when a connection test from the planned GoAlert host succeeds and the pgcrypto extension is confirmed present in the database.
Set the data encryption key on every instance
The platform team generates one data encryption key and stores it in your secrets manager, then supplies the identical key to every GoAlert instance. GoAlert uses it to encrypt sensitive values such as API keys before they are written to the database, so a mismatched key on any node will cause failures. The step is done when each instance starts with the same key and a test integration credential written by one instance can be read by another.
Deploy the default instance and API-only instances
Deploy GoAlert as a single binary or from the goalert/goalert Docker image on EU hosts. Run one instance in the default engine mode, which handles scheduled work such as notifications and escalations, and run the remaining instances with the --api-only flag for load balancing and redundancy. Confirm that only one instance runs the engine and that a database switchover test, if you plan one, behaves as the getting started guide describes. The step is done when the default instance and the API-only instances are healthy behind your internal load balancer.
Connect identity through OIDC or GitHub OAuth
Configure login through GitHub OAuth or an OpenID Connect provider that your EU identity team operates. If your identity system is not directly compatible, deploy Dex to bridge it, as the GoAlert documentation suggests. Confirm that the identity provider itself is hosted within your approved EU boundary, since login traffic carries personal data. The step is done when a test on-call user signs in and sees only the services and schedules they are authorized for.
Configure Twilio and confirm its processing location
Create a Twilio account for SMS and voice, since Twilio is currently the only supported provider for GoAlert notifications, and configure the credentials in GoAlert. Ask Twilio in writing where it processes and stores message and call metadata and content for the account and sender numbers you will use, whether EU processing options apply to your products, and what subprocessors and transfer mechanisms it relies on. Record the answers in your transfer assessment, because paging content and phone numbers are personal data. The step is done when a test SMS and a test voice call reach a registered number and the Twilio location answers are filed.
Wire Prometheus and Grafana alert sources
Point Prometheus Alertmanager or Grafana alerting at the GoAlert integration endpoints for your services, using the Prometheus and Grafana alert source types that GoAlert documents, and keep the monitoring stack inside the same EU boundary. Map each alert source to the correct service and escalation policy. The step is done when a test alert fired from Prometheus or Grafana creates an incident in GoAlert with the expected service and responder.
Run parallel paging tests before cutover
Run GoAlert alongside the existing paging tool for a defined period agreed by your incident management owners, sending test incidents through both systems to compare which responders are paged, in what order and through which channel. Include Slack escalation steps and email-created alerts if you use them. Only move production routing after every escalation path has produced the expected result and the on-call owners have signed off. The step is done when the test log shows matching paging behavior and the cutover decision is recorded.
Questions buyers ask about EU hosting for on-call paging
Does running GoAlert in the EU solve data residency on its own?
No. Hosting GoAlert inside your EU infrastructure keeps the scheduling and escalation database in the EU, but residency also depends on where notifications are processed. GoAlert's only supported provider for voice and SMS is Twilio, so each page, call and text passes through Twilio's systems. Remote access from a third country to your servers for support or administration also counts as a transfer under EDPB Guidelines 05/2021, so your support model needs the same review. Map every processor and access path, not just the database.
What does the work need from our own team?
Your team needs people who own the infrastructure, identity and telephony pieces. GoAlert is distributed as a single binary with Docker images, and its only hard requirement is PostgreSQL, which must have the pgcrypto extension. Someone must manage the data encryption key, which must be the same on every instance, and provision PostgreSQL high availability. You also need an owner for Twilio accounts, phone numbers, sender registrations and monitoring integrations such as Prometheus and Grafana. Ask your provider to confirm which of these your team will hand over during the engagement.
What makes the effort go up or down?
The two biggest drivers are the number of integrations and the identity setup. Each alert source, such as a generic API, email ingress, Grafana, Prometheus, Site24x7 or Sensu, needs its own configuration and testing. Login through GitHub OAuth or an OpenID Connect provider is simpler when your identity system already supports it. Dex is suggested as a bridge for other systems, which adds another component to run. Escalation policies with many teams and regions also take longer to validate than a single rotation.
Can we run the paging system ourselves after the engagement?
Yes, if your team takes on the operating tasks. GoAlert is Apache 2.0 licensed, so there is no license fee to pay, but you carry the hosting, database backups, upgrades and Twilio usage. Upgrades should be tested against a staging instance before production. For multiple instances, such as in a Kubernetes cluster, GoAlert recommends one instance in the default engine mode and the rest with the --api-only flag. Decide early whether your team will own on-call for the paging system itself, because a paging outage is hard to hide.
How do the EU Data Act switching rights affect our planning?
The Data Act, applicable since 12 September 2025, gives customers the right to switch from a data processing service to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027 under Articles 25, 29 and 50 of Regulation (EU) 2023/2854. Use these rights as leverage in renewal talks with your current vendor, and confirm with your legal team whether they apply to your contract. Do not assume they cover every service element, such as telephony.
What should a written quote for this work include?
A useful quote lists scope, deliverables and timelines before work starts. Ask for the components in scope: hosting design in your EU infrastructure, PostgreSQL setup and backups, encryption key handling, identity integration, alert source configuration, Twilio setup, migration of services and schedules, parallel paging tests, documentation and handover. Ask which items are one-time and which recur, such as support or upgrades. Confirm what is excluded, including Twilio usage charges, which you pay directly. Ask how DPIA and transfer documentation are prepared, and that auditors, not the provider, issue any attestation.
What should we confirm with PagerDuty and Twilio before we decide?
Confirm with PagerDuty which EU region your data would sit in, what a move to the EU region costs or requires, and whether incident history can be exported through its REST API on the EU host. Confirm with Twilio where SMS and voice processing happens for your numbers, which sub-processors it uses, what transfer mechanisms cover them, and how it handles lawful access requests. Ask both vendors for their data processing addenda and written statements on sub-processors. Keep those answers on file for your records of processing.
Evidence auditors and regulators ask for
Auditors and data protection authorities look for documents that show where personal data goes, who can reach it, and how you would leave a provider. The cards below cover the records that connect a self-hosted GoAlert deployment to those questions. Independent auditors and regulators make the final determination; DeployOpen prepares the evidence but does not issue audit reports, attestations or certifications.
Transfer assessment records under Chapter V
Keep a dated record of whether any personal data leaves the EEA, including remote access from a third country. Under EDPB Guidelines 05/2021, even viewing data on a screen for support counts as a transfer, so the file should cover support staff locations and vendor admin access. Check whether your GoAlert runbook or Twilio support process ever exposes contact details outside the EEA, and record the answer even when it is no.
Data flow map covering Twilio
Draw each path a page takes: from the alert source, through GoAlert in your cluster, to the PostgreSQL database and then to Twilio for SMS or voice delivery. Mark which hops carry phone numbers and message content, and where Twilio processes them. Confirm the processing region and any sub-processors with Twilio directly, since GoAlert itself does not decide where that traffic is handled.
Encryption key and access control configuration
GoAlert recommends a data encryption key so that sensitive values such as API keys are encrypted before they are written to the database, and the same key must be on every instance. Keep evidence of how the key is generated, stored in your secrets manager, rotated and restricted. Pair it with records of who can reach the database, the admin console and the login provider, including GitHub OAuth or the OpenID Connect provider you configure.
Supplier contracts and standard contractual clauses
Collect the signed agreements with every processor in the chain, including Twilio and your hosting or database provider. Where a transfer to a third country remains, check that the clauses follow Commission Implementing Decision (EU) 2021/914 and that a transfer impact assessment supports them. If you rely on a US provider's Data Privacy Framework certification, record that status and note that the related appeal in Case C-703/25 P is pending.
Switching and exit plan under the Data Act
The Data Act gives customers the right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition, and bans switching charges from 12 January 2027. Document how you would export schedules, rotations and escalation policies, and how you would move the PostgreSQL data, so the exit path is tested rather than assumed. Ask your current PagerDuty contract how it handles export and deletion.
What moving off PagerDuty means for schedules and history
Plan the move as two separate jobs: a data export that PagerDuty's REST API can support, and a manual rebuild of everything the API does not carry across. Services, schedules and escalation policies can be pulled through the REST API, and you choose the US or EU host when you call it, so confirm which host holds your account before you write any export script. Integrations and notification rules are not a like-for-like transfer. Each monitoring source, such as Prometheus or Grafana, must be re-pointed at GoAlert, and notification rules must be recreated in GoAlert's own terms. Treat the export as a read-only snapshot you can archive for audit, and expect incident history to stay with the PagerDuty record unless you deliberately preserve it elsewhere. The step-by-step export and rebuild sequence is covered in the sibling export and migration pages.
Because the EU host and the EU-hosted GoAlert deployment are different decisions, record which data classes you are moving and where they will sit before you negotiate. The EU Data Act gives customers of data processing services a right to switch to another provider or to on-premises ICT infrastructure. It applies from 12 September 2025, with a maximum two-month notice period and a 30-day transition, and it bans switching charges from 12 January 2027 under Articles 25, 29 and 50. Use these dates as context when you ask PagerDuty for an exit plan, a data return format and written confirmation of any fees that apply before the ban takes effect. Ask your counsel to confirm how these provisions apply to your contract, since the Regulation's text governs and this page does not give legal advice.
Put the export and switching terms into the written scope for any implementation partner, with named owners for the API token, the export archive and the cutover date. Ask the partner to confirm in writing which PagerDuty fields it will export, which it will recreate by hand and which it cannot reproduce. Keep the archive in your own EU storage under the same access controls as the rest of your incident data, and set a retention date for it. The quickest way to find gaps is a dry run against a copy of one real rotation and one escalation policy, which will show whether notification steps and contact methods survive the move before you rely on them during an outage.
Risks to plan for in an EU self-hosted paging deployment
Moving paging into your own EU infrastructure removes one vendor dependency but adds ones you now own: the notification path, the database, the encryption key and the escalation logic. Each card names one of these risks and the check that keeps it from surfacing during a real incident.
Notification path leaving the EU
GoAlert sends SMS and voice through Twilio, currently the only supported provider for those notifications, so the message content and recipient numbers pass through Twilio's processing even when GoAlert runs in your EU cloud account. Map where Twilio processes each message type, confirm the account and messaging region with Twilio, and document whether any step in that path involves a third-country transfer or remote access from outside the EEA. Treat that map as a review item before go-live, not an assumption.
Single PostgreSQL instance in an outage
PostgreSQL is GoAlert's only hard requirement, and a single database instance becomes the point of failure for every schedule, escalation and notification. Run more than one GoAlert instance behind a shared database, designate one in the default engine mode and the rest with the --api-only flag, and rehearse a database switchover so the on-call path survives a node loss. Confirm the PostgreSQL version your platform team supports, since GoAlert recommends PostgreSQL 17 or newer for new installations.
Loss of the encryption key
GoAlert recommends a data encryption key that protects sensitive values such as API keys before they are written to the database, and every instance must use the same key. If that key is lost or rotated without a plan, encrypted fields become unreadable and paging can stop working after a restore. Store the key in your existing secrets system, back it up separately from the database, and test a restore that uses only the key and the backup set.
Untested escalation after cutover
Schedules, escalation policies and rotations rebuilt in GoAlert can differ from PagerDuty in small ways that only show up when a page is raised. Before cutover, run test alerts from each alert source, including the generic API, email, Grafana and Prometheus, and confirm that every escalation step reaches the intended person by SMS, voice and Slack. Keep the old paging path active in parallel until those tests pass across a full rotation, and record the results as evidence for your change record.
How DeployOpen deploys GoAlert under EU residency constraints
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For EU residency, that means GoAlert, its PostgreSQL database and the notification path to Twilio are placed and reviewed inside the infrastructure the client controls.
How we scope
- Scope is agreed in writing before work starts, covering which EU region and hosts run GoAlert and PostgreSQL.
- The written scope lists every notification path, including which Twilio products and processing locations you have confirmed.
- Engagements are fixed-scope, and ongoing support is available as a retainer after handover.
How we build
- Deploy GoAlert as a single binary or Docker image, with PostgreSQL 17 or newer and the pgcrypto extension.
- Configure the data encryption key so API keys are encrypted before they reach the database, with the same key on every instance.
- Set up multiple instances with one engine instance and the rest in API-only mode, then test database switchover.
How we hand over
- Deliver architecture diagrams, data flow maps and a record of where personal data is stored and processed.
- Document runbooks for rotations, escalation changes, key handling, backups and restore tests.
- Provide evidence and configuration records your auditors can review, while independent auditors issue any assessment outcome.
How we support
- Support covers upgrades to new GoAlert releases, security patches and PostgreSQL maintenance on your schedule.
- Continuous security testing of the GoAlert deployment and its integrations can be added to a retainer.
- Support scope, response expectations and review cycles are fixed in the retainer agreement before it starts.
