Build time timeout?
I'm currently on the free trial plan and when I build my Swift Vapor project in release mode, it fails at 10 minutes. In debug mode it builds faster (~ 4 min) so it works fine. But as I move close to releasing in production I'd like to make sure it will build just fine. Is there an official build timeout? Will I get a higher timeout if I move to the Hobby or the Pro plan?
21 Replies
Project ID:
514d89a5-dd8e-4c00-87ad-520e173a207f514d89a5-dd8e-4c00-87ad-520e173a207f
the Hobby plan has a longer build timeout than the trial plan, and the pro plan has a longer build timeout than the Hobby plan.
but you should not be concerned with the build timeout, you would want to figure out why building your app for production is taking 10 minutes, I'm assuming that is not normal for a swift vapor app?
Swift is pretty known to have slow compile times, especially in release mode where it optimizes a lot of stuff (for better runtime performances). As a reference, on my Macbook Pro M3 Max (48Go ram), the command
swift build -c release --static-swift-stdlib takes 58s to complete, while swift build -c release --static-swift-stdlib takes 165s (so ~ 2.85x). The whole build in debug on railway takes ~ 4min, so I guess in release it takes ~ 11-12min ?well you get 20 minute build times on Hobby so that should be good?
yes it should be (hope so)
I planned to take the pro plan, to have EU servers
pro plan has even longer allowable build times, though I don't remember it off the top of my head
if I deploy from cli, does it build the docker image on my machine and deploy it to railway, or the build is still done on railway?
still done on Railway
though you can deploy to any one of our supported registries - https://docs.railway.app/reference/services#docker-image
keep in mind you will need to build an x64 image, we don't support ARM
I'm quite novice at backend stuff (I'm a iOS developer) so I'm not really familiar with all that Docker can offer, I'll try to take a look to registries but I have to admit that the kind of "plug and play" side of railway is what interested me the most π
well railway doesn't charge for builds at the moment so if you are cool with waiting then railway up away!
or GitHub, whatever you prefer
does "at the moment" mean "but anytime soon"? π
we don't currently have any plans to charge for build
ok thanks
Side question : if I want to build 2 vapor apps defined in separate
Dockerfile.server and Dockerfile.client files in the same directory, I have to pass the dockefile path as environment right?correct, did you need the name of that variable?
No I already found it a while ago, I'll be able to find it again ^^
sounds good
Can I have 2 services that shares the same build but have different run commands ? I wonder if I can build my vapor app only once, but run it as the client or as the server π€
each service has separate build context so not natively, you would need to build and publish an image (GitHub action and ghcr) and then have Railway run that image while overwriting the entrypoint of the image (start command in service settings?
or you could get really funky, single service but start two processes within the same container using parallel
interesting. But if one of the processes crash, what happens ? both terminates and railway start them both again right? I would need to handle independant process restart myself?
GNU parallel handles that for you, when correctly configured it will do just that!
https://github.com/railwayapp-templates/browserless-v2/blob/main/scripts/start.sh
the false is there to make sure the container exits with an error code, in case one of those two commands exits with a non error code for some reason, parallel will exit with its child's exit code, there's no scenario where those should ever exit so if they do, it will always count as a container crash so Railway can restart.
keep in mind, this option only works if both your client and server are http servers, because then you can use target ports to expose them both publicly - https://docs.railway.app/guides/public-networking#target-ports