rpuls
commented
2 weeks ago Thank you for the comprehensive PR and thorough description of your improvements. 🙂 There are a few challenges with the current build approach:
- A custom build command cannot be defined from the Railway template definition, and this repo belongs to a template.
- To ensure only tested dependencies are used, pnpm must rely on the lockfile.
- Running pnpm install twice is slow, and at Railway, you pay for disk space per time unit. Having two sets of identical node_modules (one in the root and one in
/.medusa/server) is an expense I'd like to avoid.
I'll see if I can come up with a solution
aleciavogel
I used your starter and got stuck earlier this week, so these are a few of the changes I made to get properly up and running.
Summary
pnpmfor semi-faster build times in the backendemailpassauth module as it breaks the invitation system (unlike the one that comes pre-installed). Kept giving meIdentity already existsin the console when I tried to register via the invite link. (There is a chance you may need to wipe the postgres volume or do some migrating if you get an error due to the provider with the customemailpassid not existing anymore)Follow best practices for building (in other words, no more post-build script)jk we're keeping itinvite.resentevent to the invitation subscriber, as I was super confused as to why the "Resend invite email" button wasn't working :Dworkerandserverper the official deployment docs, I've added the ability to add optionalWORKER_MODEandMEDUSA_DISABLE_ADMINenvironment variables that default to'shared'andfalserespectively.Railway Changes
Original railway changes discussed
In order to get this new version deployed on Railway, you'll need to make the following changes in the `Backend` service: 1. On Railway, update the Backend's custom Build script setting to: ```bash pnpm run build && cd .medusa/server && pnpm install ``` 2. Update the Backend's custom Start script setting to: ```bash cd .medusa/server && pnpm start ``` 3. Add `STRIPE_API_KEY`, `STRIPE_WEBHOOK_SECRET`, `RESEND_API_KEY`, and `RESEND_FROM` variables to the Backend. 4. Add the `/backend/**` watcher so it doesn't run a new deployment in the backend for changes made in the frontend. *** If anyone is worried about image size due to running `pnpm install` twice but doesn't want to go down the Dockerfile rabbit hole with Railway, one workaround could be: 1. Build locally via `cd backend && pnpm build` 2. `cd ./.medusa/server && pnpm install` 3. Use the [Railway cli](https://docs.railway.app/guides/cli) to deploy the `.medusa/server` folder directly (ie, `railway up` after running `railway link`) 4. Replacing the custom Build script on Railway with `pnpm exec init-backend` (or alternatively, running `railway run pnpm exec init-backend` if I'm wrong about how `railway up` works) and deleting the custom Start script setting However, this approach will prevent you from being able to use a CI/CD workflow and the automated PR branch environments in Railway without further work (like creating a github workflow, etc) Another idea I randomly had is not ignoring the `.medusa/server` folder and simply changing the Root Directory on Railway to use that as its source. You'll either need to build locally or have a github workflow that adds and commits the files for you upon merging to your `main` or `master` branch. Then just follow Step 4 in the list above to update your Railway settings for the Backend service accordingly. This way, you still get to keep a CI/CD workflow and minimize the size of the image.Add
STRIPE_API_KEY,STRIPE_WEBHOOK_SECRET,RESEND_API_KEY, andRESEND_FROMvariables to the Backend.