Regional should actually mean something

Regional processing is starting to feel like one of those phrases that can mean whatever a vendor needs it to mean.

Put the main database in Sydney and apparently you can call the whole service regional. Never mind that the message can still pass through queues, logs, account systems, and operational tooling somewhere else.

That might be a boring architecture argument if email were harmless. It isn't. A single email can carry a passport scan, a medical result, a password reset, or a private conversation. Nobody looks at that information and thinks it should take a sightseeing trip around the world.

I cannot get past how ridiculous that is. A company can say customer data is handled in Australia while the sensitive part of the workflow leaves the country. The database location gets the headline. The route taken by the actual message gets buried in the fine print.

Most software teams do not discover the problem when they choose an email provider. They discover it years later when a security reviewer asks where message data is processed. A decision that took an afternoon now threatens a deal, and the engineering team has to explain an architecture it never expected to defend.

The customer does not want a lecture on distributed systems. They want a straight answer. Instead, that answer is usually scattered across product pages, subprocessor lists, support tickets, and caveats about what “regional” was supposed to cover.

By then, the team is stuck asking for an exception or rebuilding on raw cloud infrastructure. Somehow a company that wanted to send password resets is now expected to become an email platform company. I do not buy that those are the only choices.

I am building Boundry because regional processing should not be this slippery. We are starting with transactional email in Sydney. A project gets one permanent region. The region belongs to the project; it is not a preference somebody can change later.

The dashboard asks the control plane for a short-lived project session, then calls the regional API directly. The control plane does not relay the message. Project credentials stay scoped to that project and region.

Boundry runs project message operations and configured application storage in the selected regional plane. There are still parts outside the boundary, and hiding them would make us no better. Public requests transit Cloudflare. Clerk handles account identity centrally. After delivery, the recipient mailbox provider is outside Boundry's control.

Sydney is the only live Boundry region today. Anything else is roadmap until the infrastructure exists and the evidence is ready. I would rather publish an awkward limitation than bury it under a confident regional claim.

I want an Australian software team to be able to say, without flinching, that the project runs in Sydney. Then show the architecture, the exceptions, and the evidence. No treasure hunt. No word games.

Software teams stopped running their own databases because somebody made the hard parts a product. The same thing should happen here. Keeping customer data in-region should not require a side quest into email infrastructure.

Honestly, I am annoyed this needs to be a company at all. But it does. So Boundry starts with email, one permanent project region, and no pretending about the parts outside it.