August 21, 2026

Upgrading Halo's Infrastructure: Faster, More Scalable, and Built for the Future

We're excited to share some big changes coming to the infrastructure behind Halo. Over the coming months, we're migrating our application servers to AWS EKS (Elastic Kubernetes Service) - a modern, containerised hosting platform that will make Halo faster, more resilient, and give you more control over how and when you upgrade. If you're on our Stable channel, none of this will affect you until Q1 2027 - this update is being introduced gradually, starting in Beta, so you have plenty of time to prepare.

Most of this work happens behind the scenes, but there are a few changes you'll want to be aware of - especially if you manage IT, security, or integrations for your organisation. Again, Stable customers won't see any of this until Q1 2027, so there's no need to act today - read on for the details and the full rollout timeline below.

Rollout Timeline

This upgrade is rolling out in phases:

  • September 2026: Available first in our Beta channel, in version 2.252.
  • October 2026 (version TBC): The Automations microservice becomes available in Beta.
  • November 2026 (version TBC): The Bulk Email Service becomes available in Beta.
  • Q1 2027 (version TBC): General availability in our first Stable release of the year.

We'll share more specific dates as we get closer to each milestone.

What's Changing

Containerised, cloud-native architecture

Our application builds are moving from traditional servers into containers running on Kubernetes. This makes our deployments faster, more consistent, and easier to roll back if anything ever needs correcting - meaning fewer disruptions for you.

Dramatically faster scaling

Halo already scales automatically to handle demand, but with Kubernetes this happens far quicker - around a 95% reduction in scale-out time compared to previously. In practice, that means Halo responds to traffic spikes much faster, keeping things running smoothly during your busiest periods.

Faster load times, everywhere in the world

We're rolling out AWS CloudFront to serve content from edge locations around the globe, caching it closer to wherever your team is working. If you have international teams, you should notice a real improvement in load times.

Smaller, faster responses

API and web responses will now be compressed in transit, cutting down on payload size - a win for performance, particularly on slower connections.

Automations, rebuilt as a dedicated microservice

We're extracting our Automations engine out of the core application and SQL database into its own Kubernetes microservice and worker set-up. This means more consistent automation performance and less load on the database overall — which benefits the whole platform. During the transition, a Change Data Capture process will keep this data synced back to SQL Server; over time, this data will live natively in DynamoDB.

A dedicated Bulk Email Service

We're also launching a new Bulk Email Service purpose-built for mail campaigns, dramatically increasing our ability to send high-volume campaign email — supporting millions of campaign emails per year, with better deliverability and throughput than today.

You're in control of your upgrades

We're introducing self-service version management. A scheduled upgrade window will open ahead of each release, admins will be able to deploy upgrades on demand once it opens, and your full version history will be visible right from your admin area. Worth noting: this won't all be available from day one. Initially, the admin area will only let you view your version history - the self-service action buttons to deploy upgrades will follow a little later. We'll share exact timing closer to release.

What This Means for Your IT Team

A few changes are worth flagging to whoever manages your network, security, or integrations:

  • New egress IP ranges. The egress (outbound) IPs used for integrations, outbound mail, and web requests are changing. This doesn't affect inbound traffic — only requests originating from Halo out to your systems. The updated ranges will be published at https://www.usehalo.com/guides/1446 — please update any firewall allow-lists or mail relay rules that reference our current IPs.
  • Certificates: certificate management is moving to be handled entirely on our side going forward. This affects all customers with a certificate configured for their domain, including those on an Amazon-issued certificate — you'll need to add new DNS records to support certificate validation, which we'll share directly with you. Keep your existing DNS records in place until you're on version 2.252 — removing them earlier will break certificate validation on your current version. If you access Halo via a non-Halo (custom) domain, you'll be locked to version 2.250 until the required DNS changes are made. We'll reach out directly with next steps.
  • A User-Agent header is now required on all API calls to Halo. Most integrations already send this by default, but older or custom scripts may need a quick update.
  • IP-based access restrictions are moving into the Halo application itself as a configurable admin setting, rather than being managed at the network/infrastructure level. No action needed — we'll share more detail closer to release.

What You Should Do Now

  • Check whether your team relies on any of the IPs, certificates, or headers mentioned above
  • Bookmark https://www.usehalo.com/guides/1446 for the latest IP ranges once published
  • Share this post with your IT or network team
  • If you have custom reports or integrations reading directly from our Automation, AutomationIteration, AutomationVariable, or WebhookEvent tables, get in touch with your Halo contact so we can help you plan a smooth transition

We'll continue to post updates here as we get closer to each rollout milestone. If you have any questions in the meantime, reach out to your Customer Success Manager (CSM).

Have questions about this migration? Contact your Customer Success Manager (CSM) or check our status page for the latest updates.