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.
How do I move my app off the builder's subdomain to my own?
Point the DNS and issue a certificate, then deal with everything that still lives on the builder's infrastructure: images served from its CDN, the database and auth it provisioned, and redirects from the old address so search results and existing links survive. The domain is the easy half. The assets and the redirects are what get forgotten.
The rest of this page is why that happens, how to tell which case you have, and what fixing it involves.
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 afterward. 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 keep working while the builder project exists. We copy them to storage you own and redirect the old URLs, because deleting the project deletes them.
Other things we fix the same way
- 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.”
From the products we build
Free tools and guides from software we built and run ourselves.
- pigeonatlas.comSPF, DKIM and DMARC, explained by what actually breaksThree DNS records with three different jobs, and the specific ways each one fails without telling anyone.Read it
- serverinspector.comFree website health checkUptime, SSL, domain expiry, DNS and security headers, scored out of 100 in about twenty seconds, with no account.Read it
Next step
Tell us the symptom. We will tell you if it is one problem.
We typically reply within 48 hours with what it is, whether one fix covers it, and what we need from you. If it is bigger than one problem, we say that instead, before anything is agreed.
