If you are approaching this as a procurement or compliance question rather than a settings one, our companion guide frames the same decision around latency and jurisdiction. This one covers the mechanics: which regions exist, what picking one changes, and what a move actually involves.
Most teams pick a live chat provider without ever asking where the conversations will physically sit. It rarely comes up during a trial, and then it comes up all at once — in a security questionnaire, in a procurement review, or in a conversation with a customer who wants to know whether their support history leaves the country.
MyLiveChat lets you choose. The setting is small and easy to miss, and the choice behind it is worth making deliberately rather than inheriting.
Four regions, and what the default really means
There are four hosting regions to choose from:
- Dallas, Texas, United States — the default.
- London, United Kingdom — for UK and wider European traffic.
- Beauharnois, Quebec, Canada — Canadian and northeastern US traffic.
- Sydney, Australia — Oceania.
The important detail is the first one, because Default is not the name of a server. If you select Default, the system resolves a region from the time zone on your account rather than pinning you to Dallas. For most accounts that lands in the United States, but it is a derived value, not a fixed one — which means that if you have ever changed your account time zone, Default may not point where you assume.
If your answer to where is our chat data held needs to be stable enough to write into a document, choose a named region rather than leaving it on Default. A named region is an explicit fact. Default is a calculation.
What the choice changes
The region determines which server your account's chat data lives on: the conversations themselves, the visitor records attached to them, and the operational data the chat system keeps alongside. When a visitor opens the widget, that is the server they connect to.
There is a performance dimension as well as a jurisdictional one. Chat is a real-time medium, and the round trip between a visitor's browser and the chat server happens on every message and every typing indicator. A UK visitor talking to a UK-hosted account has a meaningfully shorter path than the same visitor talking to a Dallas-hosted one. It is not the difference between working and not working, but it is the difference between a conversation that feels immediate and one that feels slightly behind.
Choose on whichever of the two matters more to you. If a regulator or a customer contract is driving the decision, jurisdiction wins and there is nothing to weigh. If nobody is asking, put the data near the majority of your visitors.
What it does not change
Being honest about the boundaries of this setting matters more than the setting itself, because a hosting region is frequently mistaken for a compliance outcome.
Choosing London means your chat data is held in the United Kingdom. It does not, by itself, make your chat deployment compliant with any particular privacy regime. Our wider security and privacy practices are documented separately, and hosting region is one line in that picture. What you collect in a pre-chat form, how long you keep transcripts, who on your team can read them, and what you tell visitors are all still your decisions, and they are the ones an assessment will actually turn on. Data location is one input to that assessment, and usually not the hardest one.
It also does not change your own obligations elsewhere. If you export transcripts into a spreadsheet on a laptop in another country, the hosting region of the original has stopped being the interesting fact. That failure mode is common enough to be worth planning for, and it is covered in the guide on transcript retention.
Two conditions a move has to meet
Changing region is not a toggle that takes effect on the next page load. Two conditions gate it, and both produce a specific refusal rather than a silent failure.
It is a paid-plan feature. On a free account the save is refused with a message telling you the feature is restricted. Nothing is changed and nothing is queued.
Every agent has to be signed out. Before the move starts, the system asks your current server whether anyone is connected. If any agent is online, the save stops with Agent online, please logoff agent console and try again later. This is not a soft warning that you can dismiss. Close every agent console — including the one in the tab you forgot about, and any mobile session — then try again.
The practical consequence is that a region change is a scheduled maintenance task, not something to do between chats. Pick a window when the team is genuinely offline.
How the move actually runs
The move is a real data migration rather than a flag flip. The destination server is asked to clone your account's data from the source server, and the save waits for that clone to report completion before it records the new region against your account.
The ordering is the reassuring part. Your account is only updated after the clone finishes successfully. If the clone fails or the connection breaks partway, the new region is never written and your account continues to run from the server it was already on. A failed move leaves you where you started rather than stranded between two servers.
What you get in the failure case is a generic An error occurred. Please try again later. It is deliberately non-specific, so if a move fails twice in a row, the useful next step is to contact support with the time of the attempt rather than to keep retrying and hoping.
One small behaviour is worth knowing because it is genuinely useful: saving the region you are already on does not trigger a migration, but it does clear the cached routing that points visitors at your server. If your widget is behaving as though it is talking to the wrong place after some other change, re-saving your current region is a safe, no-op way to flush that cache.
Your chat widget is loaded from your account's chat server, which means the hostname in the embed code is region-specific. Move regions and that hostname changes.
For most sites this is invisible, because the embed code resolves the right host automatically. It stops being invisible if you have a Content Security Policy that names an exact hostname rather than allowing the whole mylivechat.com domain. In that case the policy will keep permitting the old server and quietly block the new one, and the widget will simply not appear — with the explanation sitting in the browser console where nobody is looking.
If you run a CSP, check it before you move rather than after. A wildcard entry covering the provider domain survives a region change; a pinned hostname does not. The same applies to any firewall allowlist, corporate proxy rule, or ad-blocker exception your own team relies on to reach the agent console.
Choosing a region on purpose
A short decision procedure covers almost every case:
- Is anyone contractually or legally asking where the data sits? If yes, choose the named region that satisfies them, and write it down along with the date you set it.
- If not, where are most of your visitors? Choose the nearest region and take the latency improvement.
- Are you already live? Then treat the change as maintenance: schedule it, sign everyone out, and check your CSP first.
- Do it early if you are going to do it. The move gets no harder as you accumulate history, but the maintenance window gets harder to find.
The most common mistake is not choosing the wrong region. It is leaving the question unexamined until someone external asks, and then discovering that the honest answer is we never decided.
Put it into practice
- Look up where you are now before assuming. If the setting reads Default, your region is derived from your account time zone.
- Decide on a driver — jurisdiction or latency — and choose accordingly instead of splitting the difference.
- Check your Content Security Policy for a pinned chat hostname, and widen it to the provider domain before moving.
- Book a window with every agent signed out. The move refuses to run while a console is connected.
- Record the region and the date somewhere your security questionnaire answers are kept, so the next person does not have to rediscover it.
Where data lives is one of the few chat settings that is easier to get right on day one than in year three. It is also one of the few that somebody outside your team will eventually ask about in writing. Deciding it deliberately costs a few minutes, and the answer holds for years.