fly.io sitch from domain.
I have to switch my application from domain, what is the best way to do that? i need to change server side domain as well as client side domain? Also my database domain or how does that work?
10 Replies
Hi @Sven. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
To switch your app to a new domain on Fly.io you mainly need to:
1. Point the new domain to the right Fly app(s)
For each Fly app that should be reachable via the new domain (typically at least the client, and optionally the server):
- Add the domain / cert on Fly:
Fly will output A / AAAA records to add to your DNS for the domain you’re configuring.[Custom domain]
- In your DNS provider, add the A and AAAA records exactly as Fly instructs.[Custom domain]
You do not normally change your database “domain”: Fly’s managed Postgres URL in
DATABASE_URL stays the same, since it’s not exposed to end‑users and doesn’t depend on your public domain.[Env vars]
2. Update server environment variables
On the server Fly app, update:
- WASP_WEB_CLIENT_URL → set to the new client URL (including path if you use baseDir, e.g. <https://newdomain.com/my-app>).[Base dir; Env vars]
- WASP_SERVER_URL → if you expose the server on its own domain (e.g. <https://api.newdomain.com>), set it to that; otherwise it can remain the *.fly.dev URL.[Env vars]
Using Fly directly:
Or via Wasp deploy CLI (server context):
These are needed for CORS and OAuth redirects.[Env vars]
3. If client path changes, update baseDir
If you start serving the client from a subpath on the new domain (e.g. <https://newdomain.com/app>), set:
and make sure WASP_WEB_CLIENT_URL includes that path (e.g. <https://newdomain.com/app>).[Base dir]
---
If you clarify exactly what your current and target URLs are (client + server), I can map which env vars and Fly apps you need to touch.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Sven, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@kapa.ai can i temporarly turn off my app without loosing any db data etc.
@kapa.ai can i temporarly turn off my app without loosing any db data etc.
Let me check the knowledge base for you again. One moment! :books:
----------------------
Yes, you can temporarily turn off your app without losing database data.
For Fly.io + Wasp:
- Stopping or scaling your app server down (e.g. to 0 instances) does not delete the Postgres database; the DB is a separate Fly Postgres app with its own persistent volume.
- Restarting / redeploying the app server also does not touch the DB, as long as you don’t change or delete the database / volume itself. [Fly prod db; Seeding prod DB]
So to “turn off”:
- You can scale the server app down or stop it (via
wasp deploy fly cmd --context server ... or flyctl), and later scale it back up.
- Just don’t delete the Fly Postgres app or its volumes; that’s where the data lives.
If you share how you deployed (Fly via wasp deploy vs manual, and whether you use Fly Postgres), I can give exact commands.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Sven, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@kapa.ai i am loosing acccess to my current domain, what do you advice me to do ?
Let me check the knowledge base for you again. One moment! :books:
----------------------
You basically have two separate concerns: keeping the app + data safe and switching to a new domain.
1. Your data and app won’t be tied to the domain
Your Fly apps (server, client) and especially your database are not tied to the domain name itself. The DB is referenced via
- a new custom domain you configure. 2. Short-term: fall back to the Fly URL If you’re about to lose the domain and don’t yet have a new one: - Make sure you can still reach the client via its
Then add the A and AAAA records your DNS provider, using the values Fly prints.[Custom domain] 2. Update the server CORS origin
This keeps CORS in sync with the new frontend URL.[Custom domain; Env vars] 3. (Optional) if you use a custom domain for the API itself (e.g.
- your current server URL
- whether you have a new domain picked out
I can map out the exact commands you should run. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Sven, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
DATABASE_URL and lives as a separate resource; losing a domain does not delete it.[Env vars]
So even if the current domain stops working, your app + DB can keep running on:
- the default *.fly.dev URLs, or- a new custom domain you configure. 2. Short-term: fall back to the Fly URL If you’re about to lose the domain and don’t yet have a new one: - Make sure you can still reach the client via its
*.fly.dev URL.
- On the server app, set WASP_WEB_CLIENT_URL to that Fly client URL, so CORS keeps working:
This tells the server which frontend origin is allowed.[Custom domain; Env vars]
3. When you get a new domain
Once you own a new domain:
1. Add it to the client Fly app and set up DNSThen add the A and AAAA records your DNS provider, using the values Fly prints.[Custom domain] 2. Update the server CORS origin
This keeps CORS in sync with the new frontend URL.[Custom domain; Env vars] 3. (Optional) if you use a custom domain for the API itself (e.g.
api.newdomain.com), also:
WASP_SERVER_URL is used mainly for OAuth redirect URLs.[Env vars]
---
If you tell me:
- your current client URL- your current server URL
- whether you have a new domain picked out
I can map out the exact commands you should run. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Sven, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
@kapa.ai but now my frontend uses api.mydomain to communicate wit hthe server, ohw do i rol that back to the old fly domain?
Let me check the knowledge base for you again. One moment! :books:
----------------------
You need to do two things: (1) point the client back to the Fly server URL and (2) update the server’s idea of the frontend URL if needed.
1. Point the frontend back to
- and your server’s Fly URL
I can give you the precise build command and secrets to set. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Sven, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
<https://<server-app>.fly.dev>
Your React client talks to the server via REACT_APP_API_URL, which becomes config.apiUrl on the client.[[Client config]]
If you currently have it set to <https://api.mydomain> somewhere in your deployment process, change it back to your Fly URL, e.g.:
Or if you use the manual Railway / static hosting flow, make sure your build command uses the Fly URL again.[[Railway client]]
If you’re using wasp deploy fly deploy for both server & client, Wasp will automatically set REACT_APP_API_URL based on the Fly server URL, so simply redeploying via:
should also reset the client to use <https://<your-server-app>.fly.dev.[[Fly> deploy issue]]
2. Make sure the server allows the correct frontend origin
The server-side CORS / Same-Origin config uses WASP_WEB_CLIENT_URL as “where the frontend lives”.[[Env vars;\ Custom domain]]
If your frontend is now served from a different URL than <https://api.mydomain> (for example, from a Fly client app URL or some static host), set WASP_WEB_CLIENT_URL to that frontend URL again:
This keeps CORS in sync, so requests from the frontend to <https://<your-server-app>.fly.dev> are allowed.
---
If you tell me:
- the exact URL where the frontend is now served- and your server’s Fly URL
I can give you the precise build command and secrets to set. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Sven, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
@kapa.ai
server: {
middlewareConfigFn: import { serverMiddleWareFn } from "@src/server/serverSetup",
},
What is this for? in main.wasp
serverSetup:
Let me check the knowledge base for you again. One moment! :books:
----------------------
-
- the additional domains you list. [Customize global middleware] So in plain terms: this is where you’re saying “for every Wasp operation and API, use this CORS setup instead of the default one, and allow these extra domains to call my backend.” ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Sven, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
server: { middlewareConfigFn: ... } in main.wasp is how you customize the global Express middleware that Wasp uses for all operations and APIs.
From the docs:
- app.server.middlewareConfigFn is “a global modification affecting all operations and APIs.”[Server config API; Middleware config fn]
- It receives a MiddlewareConfig (a Map<string, express.RequestHandler>) that contains Wasp’s default global middleware (helmet, cors, logger, json, urlencoded, cookieParser).[Default middleware]
Your code:
and
does this:
- It overrides the default CORS middleware ('cors' key) with your own instance.-
origin: [config.frontendUrl, '<https://mydomain.xx',> ...] tells CORS to allow requests from:
- the main Wasp frontend URL (config.frontendUrl), and- the additional domains you list. [Customize global middleware] So in plain terms: this is where you’re saying “for every Wasp operation and API, use this CORS setup instead of the default one, and allow these extra domains to call my backend.” ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Sven, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
no help needed here, just wanted to chat with kapa.