Ownership · hosting
Your app lives at an address someone else owns
Every bookmark, every link you have shared, every search result and every password-manager entry points at a hostname that belongs to your builder. Moving is not hard, but it breaks four things at once if you only change the DNS — and the four are exactly the ones nobody checks until a customer cannot log in.
Have the domain bought and the registrar login to hand. That is all we need from you.
- First step
- A short call, or a written description if you would rather not talk yet
- Who you speak to
- The engineer who would do the work. No account manager, no sales call.
- Turnaround
- Most single problems are resolved within 48 hours of getting access
- Cost
- Quoted after we have seen it — scope varies, and guessing helps neither of us
How to get this fixed
Already a client? Raise it as a ticket in Golux Club and it enters the queue with an SLA attached.
The four things a domain move breaks
Authentication goes first: every OAuth provider and every Supabase project has an allow-list of redirect URLs, and the new hostname is not on it, so sign-in returns to nowhere. Cookies go second — anything set for the old host is invisible on the new one, which logs everybody out and can lose carts and drafts. CORS goes third, if your API only accepts the old origin. And search goes fourth: without redirects, whatever ranking and backlinks you had point at a page that still exists, so Google keeps the old one and the new one starts from zero.
How to tell it is this
- You changed the DNS already and now nobody can sign in
- The new domain works but the old one is still live, showing the same app
- Google still lists the builder's hostname
- Email links and OAuth consent screens still say the old name
What we do
One pass, in the order that avoids downtime.
- 01
Set it up beside, not instead
The new domain serving the app and verified, while the old one keeps working. Nothing is switched until it is proven.
- 02
Update every allow-list
Supabase redirect URLs, every OAuth provider, CORS origins, cookie domain and any webhook endpoints that name the old host.
- 03
Redirect and preserve
Permanent redirects from the old hostname to the new one, path for path, canonical tags updated, sitemap resubmitted — so the ranking follows instead of splitting.
- 04
Cut over and watch
DNS changed when you say so, then sign-in, payments and email links checked on the live domain while the old one stays as a fallback.
What you get
- The app on your domain with HTTPS, and the old address redirecting to it
- Sign-in, payments and email links verified on the new host
- Canonicals and sitemap updated so search follows you
- The allow-lists written down, so the next environment is a five-minute job
When this is not what you need
- You also want off the builder's hosting entirely — that is the migration, and this work is part of it rather than a separate piece
- The domain is held by an agency or a former partner who will not release it — sort ownership first; we cannot move what you cannot control
- You want email on the domain too — related but separate; ask and we will quote it
How it works
- 01
Tell us the symptom
One paragraph is enough — the error, the screen, what you expected. Run the free audit first if you have not; it often names the problem for you.
- 02
A call, or a written reply
Thirty minutes to look at it together, or a written answer if you prefer. Either way you find out what it is before anything is agreed.
- 03
A written offer
After the call: the scope, the approach and what we need from you. Discussed on the call, confirmed in writing.
- 04
Fixed, explained, handed back
The fix in your project, a short note on what was wrong and why, and how to check it yourself — typically inside 48 hours of getting access.
What we promise before any money changes hands
We tell you what is actually wrong, whether it is one problem or a symptom of a bigger one, and what it would take — before you commit to anything. If the honest answer is that you can fix it yourself in an afternoon, that is the answer you get, and the instructions are usually on this page already.
Questions
- Will the app go down during the change?
- No. The new domain is serving before the DNS moves, and the old one keeps answering afterwards. The switch itself is a DNS record; the fallback is why it is not scary.
- Do I lose my Google ranking?
- Not if the redirects are permanent and path-for-path, which is the part that gets skipped. Rankings usually transfer within a few weeks. Skipping the redirects is how sites lose them permanently.
- Can I keep hosting with Lovable and just use my domain?
- Yes, and for many apps that is the right call for now. This fix works either way — the allow-lists, redirects and cookies are the same job whether the app stays where it is or not.
- What about the images and files already uploaded?
- They usually stay on the builder's storage and keep working. Whether to move them is a judgement call about lock-in; we will tell you what we would do and why, as part of the conversation.
Other things we fix at the same price
- Login loops or logs me straight out“Signing in bounces me back to the login page, or a refresh logs me out.”
- The build or deploy is failing“The deploy fails, or it works in preview and breaks in production.”
- I have no real backups“If the database disappeared tomorrow, I do not know what I would do.”
Next step
Tell us the symptom. We will tell you if it is one problem.
We answer within a few hours with what it is, what it would take, and what we need from you. If it is bigger than one problem, we say that instead — before anything is agreed.
