is there a way to customize the autogenerated fly.toml files for deploying on fly?

I followed the instructions to do a regular "automated" deployment with Fly, but I realized deploy comes with some assumptions such as redundant services etc that I don't really need when I'm setting up a staging environment. Based on what I've seen the fly.toml file is re-regerated in .wasp/build every time the command wasp deploy fly deploy is executed. Does it mean I need to manually deploy to Fly instead if I want to customize thier configuration?
6 Replies
kapa.ai
kapa.ai3mo ago
Hi @Sergio Visinoni. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
MEE6
MEE63mo ago
Wohooo @Sergio Visinoni, you just became a Waspeteer level 2!
kapa.ai
kapa.ai3mo ago
---------------------- Yes, you can customize the autogenerated fly.toml files for deploying on Fly.io. When you rebuild your Wasp app with wasp build, it will remove your .wasp/build/ directory, which may contain a fly.toml from any prior Fly.io deployments. Here are a few options you can consider: 1. Copy the fly.toml file to a versioned directory, like your Wasp project dir. From there, you can reference it in flyctl deploy --config <path> commands. 2. Backup the fly.toml file somewhere before running wasp build, and copy it into .wasp/build/ after. When the fly.toml file exists in .wasp/build/ dir, you do not need to specify the --config <path>. 3. Run flyctl config save -a <app-name> to regenerate the fly.toml file from the remote state stored in Fly.io. Also, if you want to maintain multiple apps, you can add the --fly-toml-dir <abs-path> option to point to different directories, like "dev" or "staging". Remember, you should only run setup once per app. If you run it multiple times, it will create unnecessary apps on Fly. For more advanced customization, you can provide your own custom Dockerfile in the project root. In that Dockerfile, you can include a line with something like cp ./my-patched-file.js server/something/somewhere.js. Wasp will use this file to build your server container instead of the default file. Please refer to the following sources for more information: - Redeploying After Wasp Builds (https://wasp-lang.dev/docs/advanced/deployment/manually#redeploying-after-wasp-builds) - Deploying with the Wasp CLI (https://wasp-lang.dev/docs/advanced/deployment/cli#setup) - Customizing the Dockerfile (https://wasp-lang.dev/docs/advanced/deployment/overview#customizing-the-dockerfile) - Discord support thread: Issue with deploying my wasp app to fly.io (https://discord.com/channels/686873244791210014/1223671727943319584) ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Sergio Visinoni, 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?
Sergio Visinoni
Sergio VisinoniOP3mo ago
@kapa.ai is it normal that after running a clean wasp build there is a Dockcerfile in .wasp/build but not one in .wasp/build-web-app? Deploying the client on Fly is failing because of that
kapa.ai
kapa.ai3mo ago
Let me check the knowledge base for you. One moment! :books: ---------------------- Yes, it is normal that after running a clean wasp build there is a Dockerfile in .wasp/build but not one in .wasp/build/web-app. The Dockerfile in .wasp/build is used to build and run a Docker image with the Wasp-generated server code and run any pending migrations. For deploying the client, you would typically use a static hosting provider. If you want to deploy your client on Fly.io, you would need to manually create a Dockerfile in the .wasp/build/web-app directory. Here are the steps to deploy the client as per the Wasp documentation (https://wasp-lang.dev/docs/advanced/deployment/manually#deploying-the-client): 1. Change into your app's frontend build directory .wasp/build/web-app:
cd web-app
cd web-app
2. Create the production build, using the server domain as the REACT_APP_API_URL:
npm install && REACT_APP_API_URL=<url_to_wasp_backend> npm run build
npm install && REACT_APP_API_URL=<url_to_wasp_backend> npm run build
3. Create a Dockerfile in the web-app directory with the necessary configuration for your static hosting provider. Remember, you'll need to repeat these steps each time you run wasp build as it will remove the .wasp/build/web-app directory. You can automate this process by creating a shell script as suggested in the Wasp documentation. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Sergio Visinoni, 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?
miho
miho3mo ago
If you modify the TOML files in the root of the app e.g. fly-server.toml and fly-client.toml - Wasp will use those files when running the deployment with the CLI. We don't provide a default Dockerfile for the web-app because we didn't want to assume if you'll deploy to Cloudflare Pages, Github Pages which are static page hosting vs. Fly which uses Docker to serve the client. In this section of the docs you can find our recommended Dockerfile for the client if you need it and some other tips: https://wasp-lang.dev/docs/advanced/deployment/manually#deploying-the-client
Want results from more Discord servers?
Add your server