Do client secrets have to be included in every redeploy or only for the first one?
It looks to me as if it's required to add the REACT_APP_STRIPE_CUSTOMER_PORTAL... before the wasp deploy fly deploy command every single time when redeploying.
Have I misconfigured something or this this intentional?
If it is meant to be like this, wouldn't it be much more convenient if the deploy command would grab that secret from env.client automatically?
11 Replies
Hi @fred-123. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
You're correct about how client environment variables work with Wasp deployments. When using
wasp deploy fly deploy, you need to include the client environment variables (like REACT_APP_STRIPE_CUSTOMER_PORTAL) every time you redeploy.
This is because client environment variables are embedded into the client code during the build process. As explained in the documentation:
Client env vars are embedded into the client code during the build and shipping process, making them public and readable by anyone. Link to Env Variables docsUnlike server environment variables which are stored on the server (via
flyctl secrets set or similar), client environment variables must be provided at build time. When you run REACT_APP_SOME_VAR_NAME=somevalue wasp deploy fly deploy, Wasp replaces all occurrences of import.meta.env.REACT_APP_SOME_VAR_NAME with the actual value during the build.
This is intentional behavior, not a misconfiguration on your part. The Wasp team has acknowledged this might not be the most convenient approach. In fact, there are open issues discussing improvements to this workflow:
1. There's an issue discussing whether Wasp should provide a better way to handle client environment variables during deployment: Github Issue #1354
2. Another issue discusses allowing configuration of frontend web-app env vars via the main .env file: Github Issue #675
Your suggestion about having the deploy command grab secrets from .env.client automatically is a good one and aligns with discussions the Wasp team has had about improving this workflow.
For now, you'll need to continue providing the client environment variables with each deployment using:
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @fred-123, 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 is there a way to make the deployment fail when forgetting to add it? I am worried I redeploy without it and thus hide the stripe billing section from the user which I am sure they might not be too happy about since that section is requried to cancel or upgrade subscriptions.
Let me check the knowledge base for you again. One moment! :books:
----------------------
Currently, there's no built-in way to make the Wasp deployment fail automatically when you forget to include client environment variables like your
REACT_APP_STRIPE_CUSTOMER_PORTAL variable. This is a valid concern, especially for critical functionality like subscription management.
Here are some potential workarounds:
1. Create a deployment script: You could create a shell script that includes your environment variables and runs the deployment command. This way, you only need to run the script instead of remembering to include the variables each time.
Similar to the example in the Wasp documentation for Railway deployment, you could create a script for Fly.io deployments:
Deploying Manually docs show a similar approach for Railway deployments.
2. Add client-side validation: You could add code in your client application that checks if the required environment variables are defined and shows a warning in your development environment or logs an error in production.
3. Use a CI/CD pipeline: If you're using a CI/CD system for deployments, you can configure it to always include the necessary environment variables.
The Wasp team is aware of these limitations with environment variables. There are open issues discussing improvements to how client environment variables are handled (Github Issue #175 and Github Issue #1354), but for now, you'll need to use one of the workarounds above.
The most reliable approach would be to create a deployment script that includes all your required environment variables, so you never have to remember to add them manually.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @fred-123, 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?hey @fred-123 I think this is actually no longer necessary with Open SaaS, since we now set it as an environment variable
unless of course you're using an older version of Open SaaS
you can check by looking in the paymentProcessor.ts file and if it has
fetchCustomerPortalUrlI am on an older version.
Is there any documentation on how to upgrade?
@kapa.ai
Let me check the knowledge base for you again. One moment! :books:
----------------------
Yes, there is documentation on how to upgrade Wasp. The process depends on which version you're currently using and which version you want to upgrade to.
Checking Your Current Version
First, you can check your current Wasp version by running:
How to Upgrade Wasp
You can upgrade Wasp by using the installer script with a specific version flag:
Replace
x.y.z with the specific version you want to upgrade to. If you want the latest version, you can omit the version flag:
CLI Reference provides this information when you run wasp version.
Migration Between Major Versions
If you're upgrading between major versions (e.g., from 0.11.X to 0.12.X), Wasp provides specific migration guides:
- For migrating from 0.11.X to 0.12.X: Migration from 0.11.X to 0.12.X
- For migrating from 0.12.X to 0.13.X: Migration from 0.12.X to 0.13.X
The migration guides include detailed steps for updating your project structure and code to be compatible with the new version. For example, when migrating to 0.12.X, you'll need to:
1. Install the new version of Wasp
2. Back up your project
3. Run the migration script: npx wasp-migrate your-project-name
4. Follow additional steps to update imports and dependencies
If you get stuck during the migration process, you can ask for help on the Wasp Discord server.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @fred-123, 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 for upgrading opensaas specificly. I am on wasp 0.16 already
Let me check the knowledge base for you again. One moment! :books:
----------------------
Based on the knowledge sources provided, there is specific information about upgrading OpenSaaS when using Wasp.
If you're looking to upgrade the OpenSaaS template while maintaining your own repository, there are a few things to consider:
According to a Discord conversation, the Wasp team updates the OpenSaaS template when new versions of Wasp are released. As mentioned by a community member:
"Yes! It might lag a couple of days, but we plan to update it relatively quickly." Discord support threadFor managing your own repository based on OpenSaaS while still being able to pull updates, another Discord thread provides some insight:
"Well,Since you're already on Wasp 0.16 and specifically asking about OpenSaaS, you would need to: 1. Check if there's a newer version of the OpenSaaS template compatible with Wasp 0.16 2. If you've made modifications to your OpenSaaS-based project, you'll need to manually merge the changes from the updated OpenSaaS template into your project The knowledge sources don't provide specific step-by-step instructions for upgrading OpenSaaS specifically while on Wasp 0.16, so you might want to check the OpenSaaS repository for any upgrade guides or reach out to the Wasp team on Discord for more detailed assistance with this specific scenario. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @fred-123, 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?waspis a binary that you install on your machine. So you don't save it in any way into your git repo. This is the standard way to do it across the industry,waspfollows that. Once you want to updatewasp, you will instal the new version on your dev machine, and will have to update the codebase of your app to work with neverwaspof course. For big breaking changes (like the one that is coming out any moment, wasp 0.12) we provide detailed instrutions and even scripts that do part of the job for you." Discord support thread
@kapa.ai is there something like a change log to see what has changed between the versions? Or would I have to hunt it down in the github repo?
Let me check the knowledge base for you again. One moment! :books:
----------------------
Yes, Wasp does have a way to see what has changed between versions. When you run the
wasp version command, it not only shows your current version but also provides information on how to upgrade:
As mentioned in the output, you can find the changelog information in the GitHub releases page: <https://github.com/wasp-lang/wasp/releases
There is an open issue in the Wasp repository about implementing an automatic CHANGELOG (Github Issue #223), but for now, the GitHub releases page is the official place to see what has changed between versions.
For major version upgrades (like 0.11.X to 0.12.X or 0.12.X to 0.13.X), Wasp also provides detailed migration guides that explain the breaking changes and how to update your code.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @fred-123, 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?We have migration guides in the docs and changelog on the repo