Wasp•2y ago

Deployment Questions

Hi! I'm getting very close to deploying, and I have a few questions before I do. As a bit of context, I'm an experienced web developer but I've never launched my own application.

Updates: Is there a recommended way to push updates to the live version of the wasp application? Currently I'm hosting everything on github, and would like to use my main branch as the deployed version of the app. What's best practice here?
Prisma DB Studio access for deployed app. How would I go about accessing this to manage the data for my app?
Substituting NGROK. Currently, I'm using Ngrok to test my endpoints from a mobile version of my app, but I'll need to swap that out for whatever will replace my port 3000 and 3001. I'm not sure what to expect when I cross that road.

I plan to deploy in the next two days and I'm excited! But I know I'll need to be able to keep pushing updates and I'm not sure how that all works just yet. Thanks!

kapa.ai•7/20/24, 11:06 PM

Hi @JLegendz. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

kapa.ai•7/20/24, 11:06 PM

----------------------
Sure, I'd be happy to help with your deployment questions!

Updates: To update your deployed Wasp application, you can use the wasp deploywasp deploy command. This command pushes your client and server live. You should run this command whenever you want to update your deployed app with the latest changes. If you're deploying manually, you'll need to run wasp buildwasp build to rebuild your app, then run railway uprailway up in the .wasp/build.wasp/build directory for the server, and repeat all the steps in the .wasp/build/web-app.wasp/build/web-app directory for the client. Source 1 (https://wasp-lang.dev/docs/advanced/deployment/cli#deploy), Source 2 (https://wasp-lang.dev/docs/advanced/deployment/manually#updates--redeploying)
Prisma DB Studio access for deployed app: To connect to your Fly production database, you could open up a tunnel with fly proxy 5432 -a <db-name>fly proxy 5432 -a <db-name>. After following these steps, executing wasp db studiowasp db studio should work. Just remember to remove the DATABASE_URL with the production database URL from .env.server if you put it there, to avoid accidentally making changes to the production database later. Source (🙋questionsHow to interact with database in prisma studio after deployment?)
Substituting NGROK: There's an open issue on the Wasp Github about making it easy to use different ports (other than 3000 and 3001) during Wasp development. This might be relevant to your question about replacing Ngrok. However, the issue is still open and it doesn't seem like a solution has been implemented yet. Source (https://github.com/wasp-lang/wasp/issues/730)

I hope this helps, and good luck with your deployment!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------

kapa.ai•7/20/24, 11:06 PM

Sorry @JLegendz, 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•7/22/24, 9:03 AM

Hey, we are also excited for you!

Let's go through the questions one by one.

Is there a recommended way to push updates to the live version of the wasp application?

We give a couple of ways to deploy Wasp apps: through our CLI to Fly or manually to some other providers. https://wasp-lang.dev/docs/advanced/deployment/overview

Of course, you can deploy anywhere since it's just a React and a Node.js app in the end.

One thing we don't have right now is support for Git based deployment aka deploy on git pushgit push. You have to deploy the app manually when you are ready to deploy. For example, if you decided to use Fly then you would just run wasp deploy fly deploywasp deploy fly deploy and it would build your app and deploy it.

This would push your latest client and server code. It would also push your migrationsmigrations folder which would get applied to your DB on deployment - this way your DB schema is up to date.

Prisma DB Studio access for deployed app

I'm glad you asked! I wrote a snippet here: https://github.com/wasp-lang/learning-materials/blob/main/README.md#running-wasp-db-studio-on-production-db

Substituting NGROK

So yeah, when you deploy your app it will be subdomains or domains instead of ports. Now, you have your client running at 3000 and the server at 3001. When you deploy them to Fly for example, you'll get two URLs smth like my-client.fly.devmy-client.fly.dev and my-server.fly.devmy-server.fly.dev which you'll use instead of the Ngrok links

those subdomains point to Fly's servers and work mostly the same like Ngrok links point to your machine.

Overview | Wasp

Wasp apps are full-stack apps that consist of:

GitHub

learning-materials/README.md at main · wasp-lang/learning-materials

A place to collect some useful learning materials for Wasp - wasp-lang/learning-materials

Filip•7/22/24, 12:35 PM

Hey @JLegendz, glad to see you're making it closer to the production milestone!

Miho explained it very nicely.

Still, if you want to jump on a call and sort out all the questions you might still have, just let me know!
We love helping users such as yourself!

martinsos•7/22/24, 2:51 PM

@miho deployment could be done from a specific git branch though, right?
For example, one could set up Github Action which, when something is pushed to branch releaserelease, deploys it, but first running wasp buildwasp build up in the Github Action and then also running whatver commands are needed to deploy it (e.g. wasp deploy fly deploywasp deploy fly deploy or maybe some custom commands).

As for branch names @JLegendz : you could go with one ranch called releaserelease branch -> whenever you want to release new version fo your app, you push to that branch, and then deploy that same code (either automatically as described above or manually from your machine).
And the second branch would be

main

main

, where you do development. This is how we devleop waspwasp. So every day you add stuff to

main

main

, and once you are ready, you push/merge that into releaserelease.
Some people to the opposite and use

main

main

as releaserelease, and then have developdevelop where they develop. It is same thing really though.
This approach with two branches is nice because you always check on releaserelease what is the current state of your code in production, what you deployed last, and for exapmle if your

main

main

become much more advanced in the meantime but you need to quickly fix something for version of code that is in production, you can do that fix on the releaserelease branch instead of doing it on

main

main

and having to poush all these new changes also that maybe you are not ready yet to publish. Check out online tutorials on this for more info.

JLegendzOP•7/23/24, 2:24 AM

Thanks for the response guys! I'm certainly getting close to the production milestone. I'm adding a few finishing touches, and then I need to create the production version of my stripe products, and finally integrate the stripe functionality into the mobile app. I'm using Wasp as my web app/ server, and using apis to power my mobile app. I'll be picking up dev again on Wednesday and I'll keep you all posted. I look forward to sharing in made-with-wasp when I get there. And yes I'll surely have a few questions along the way to get those finer details sorted. I appreciate the support.

martinsos•7/23/24, 10:04 AM

That is awesome -> keep asking us stuff, we are here to help, and we all learn together on the way. We should at some point write something like "production guide for Wasp apps", haven't done it yet beacuse we are in Beta but it will be coming, so discussions like this are a good foundation for it.

Deployment Questions

Similar Threads

Similar Threads

Similar Threads