Architecture and deployment regions

Your Arino One instance runs in one of three regions — EU, North America or APAC — chosen when the instance is provisioned, and that choice fixes where message content, contacts and media are stored at rest. Every customer gets a dedicated console, an isolated database and their own Infobip account, which they own and pay for directly; nothing is shared across tenants.

The layers of an instance

An instance is composed of four layers, all provisioned together:

• Console — the operator interface: inbox, CDP, automations, reporting, settings and billing.
• Data layer — contacts, conversation history, media attachments and consent records, held in your chosen region.
• Messaging back-end — your own Infobip account, holding your channel registrations, senders and numbers, created either during Remix onboarding or connected from an existing account you already had (see instance types).
• Integration layer — CRM and helpdesk connectors, plus outbound webhooks to your own systems.

This is the same architecture regardless of your onboarding route or whether you build it yourself or have Arino build it. What changes is whether the $50/month Arino Core connection is active — which determines whether Arino operates alongside you — not the shape of the stack or where data is stored.

What the region actually determines

Region governs storage location for data at rest inside your instance. It does not change how messages are routed once they leave your instance: carrier and platform delivery paths are inherently global, so a message sent to a mobile number in Sydney transits Australian and Meta/carrier infrastructure regardless of whether your instance is provisioned in Dublin, Virginia or Singapore.

Isolation within the architecture

Isolation is enforced at every layer, not just the database. Your console runs against your own application instance, your data layer is a dedicated database rather than a row-scoped table in a shared one, and your messaging back-end is your own distinct Infobip account with its own credentials — so a misconfiguration or incident on another customer's instance cannot reach yours. This isolation model is identical regardless of onboarding route, build option or connection status; self-build customisation changes the console's code, not the isolation boundary around it.

Choosing a region

Choose based on your regulatory obligations and where your data controller sits, not simply where most of your customers live. A UK-headquartered retailer selling into North America should typically still choose EU, since that is where their compliance obligations and data protection authority sit; the messages themselves still reach US numbers via global carrier routes.

Region is set once, at provisioning, on the create your instance step. It is not a setting you can toggle afterwards — moving region later means migrating data into a newly provisioned instance in the target region, then re-verifying channel connections and sender registrations there.

One contract, every region

Regardless of which region you choose, you get the same Master Services Agreement, the same Data Processing Agreement and the same support team. You are not negotiating separate terms or managing a different vendor relationship per geography — region is an infrastructure decision, not a commercial one.

How this differs by onboarding route and connection status

Region and architecture are identical regardless of onboarding route, build option, or connection status. The difference is operational, not structural:

In every case the underlying data-residency guarantee is the same: your instance's database and media live only in the region you selected, and the Infobip account is always yours regardless of whether you keep the $50/month Arino Core connection active.

Frequently asked