Deploy through github
Hey all,
Right now I have some other apps hosted on Railway.
With those apps, my workflow is to pull main/develop, create a branch, make changes then commit/push to github. In github, I make a merge request and apply to main/develop.
I like this workflow because I can theoretically develop from anywhere.
If I were to do that with Wasp, would I have to build then push to github?
I have another app that uses the railway/wasp CLI to push straight to railway, but I feel like I am rolling the dice with version control. I could also still do github but just deploy to railway
I am new to a lot of this, so I am sure versioning has been thought of, but I just don't know the best practices.
Any help would be greatly appreciated!
5 Replies
Hi @Landyn. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
You do not need to build your Wasp app before pushing to GitHub. The recommended workflow is to keep your source code (including your Wasp files and app code) in your GitHub repository, and only build the app (using wasp build) when you are ready to deploy. The build artifacts generated by wasp build (in the .wasp/build directory) are not typically committed to version control.
For deployment to Railway, the usual process is:
1. Develop locally, commit and push your changes to GitHub.
2. When you want to deploy, run wasp build locally to generate the deployable code.
3. Deploy the built code to Railway, either manually or using the Railway CLI from the .wasp/build directory.
If you want to automate deployments from GitHub (e.g., on every push to main), you can set up a GitHub Action to build and deploy your Wasp app. There is a community effort to provide a GitHub Action for Wasp deployment, as discussed in this GitHub issue and a related deploy-action repository, but this is not yet official or fully documented.
In summary, your best practice is:
- Keep your Wasp source code in GitHub.
- Do not commit build artifacts.
- Build and deploy when needed, either manually or via CI/CD (e.g., GitHub Actions).
- For Railway, you can deploy from your local machine or automate it via CI, but always keep your source of truth in GitHub.
If you want to update your deployed app with the latest changes, you can always run wasp build and then deploy, or use the CLI for supported providers like Fly.io with wasp deploy fly deploy, which pushes your latest code live Deploying with the Wasp CLI Deploying Manually.
Let me know if you need more details on setting up GitHub Actions or specific deployment steps!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Landyn, 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 @Landyn, the typical setup is to keep doing what you're doing, and have a GitHub Action deploy your app on a push to
main, is that what you're asking for?That's exactly what I'm asking! Pretty well, should I be using railway/wasp CLI to deploy or use GitHub.
Is there a tutorial on how to configure the GitHub actions? Do I need to build before deploying to GitHub?
I have no issue pushing straight to a new project, but have been struggling to deploy within an existing project.
Thanks for your help!
Ok, so if I got it right, you are asking what is the recommended approach for CD (Continuous Delivery) for a Wasp app.
There is no single correct answer, but here is what I would personally do:
- Use the git workflow you have -> you create branch off
main when building a new feature (that is called "feature branch" then), merge it into main when it is done.
- Have a Github Action that runs on merge requests / PRs, and also on main, that does CI (Continuous integration) -> meaning it basically check if the code works correctly. That means it would run any tests you might have (unit, e2e, ...). If you don't have any you could skip this step.
- Do deployment manually by running wasp deploy railway .... This gives you control over being able to manually check everything works as it should before you deploy, and if something goes wrong, and you are in full control.
- Additionally, you could not ever deploy from main, but instead from release branch -> so when you want to deploy, you merge main into release, then deploy release. That way you always know which exact code was last released (the code in release) and you can continue working on main while for example also able to push a quick hot fix to release if there is a bug in released code without having to deal with all the changes you did on main in the meantime. This is how we develop Wasp also, and you can see our "release checklist" in waspc/README.md (in wasp repo) for more details.
That said, if you want deployment to happen automatically each time you push to main, or in advanced case, to release, instead of doing it manually, then what @Carlos said, you can have a GIthub Action that will run wasp deploy railway for you. There is nothing super special about setting it up, in the sense that there is nothing very Wasp specific excpet for having it run that command, very similar like you would do it manually. I believe any LLM can help you do a good job writing that script, and we can also help if needed.
I added this to our github issue for improving deployment docs, I think it makes sense we provide some more info on this! https://github.com/wasp-lang/wasp/issues/2358#issuecomment-3476883322GitHub
Write "Going into production" docs / rewrite of deployment docs · ...
Users deploying Wasp apps sometimes get stuck and they report it on our Discord. Some of the common themes: env variables are missing CORS is not working as expected database migrations are misunde...
Thank you so much for the detailed reply. It definitely helps me wrap my head around it!