9 months ago
Since our services have been switched to Railway Metal, we have noticed that they are being re-deployed automatically by Railway.
One service in particular that is causing issues is our search service, which ran on Railway without a re-deployment for almost 9 months prior to switching to Railway Metal. With a new deployment, the indexes are wiped as its a fresh volume/deployment, leaving the search service down.
Is this an behavior we should expect from now on? That services are just redeployed automatically via Railway at random times? If so, I'm sure there's good reasons and if we need to build out a build step to reindex our search service before its deployed we can do that but was hoping we wouldnt have to.
Thanks!
16 Replies
9 months ago
Hello,
As for why we sometimes redeploy services -
For the search service that you mentioned, you would want to configure the software you are deploying to store the index data to a volume for persistence between redeploys, this will make it so that redeploys won't need to be re-indexed and thus redeploys will not cause search outages.
What options do I have to persist the index data to a volume so that it will persist between deployments? Is the approach to re-index as a buildpack step what we should be doing or is there something else?
9 months ago
Without knowing what software you are using it would be a tad hard to give pointers, would you mind sharing the software you are using for search?
If its just a matter of the newly deployed search service hydrating its indexes and documents from a data dump or some sort of index process as a build step, I'm clear on how we might solve that. I didnt know if Railway could transport the volume's search as part of the deployment or if its always going ot be a fresh build with a brand new service if that makes sense
9 months ago
I'm fairly certain my teammates template for that persists data between redeploys, give it a try! -
Are there timeouts set for build steps? Re-indexing all of our documents currently takes about 30 minutes
And Im still unclear on what can be transferred from one deployment to the next. I see this option in the link you posted for deploying Meilisearch. Lets say theres a file data.ms on deployment 1. Can deployment 2 access data.ms from deployment 1?

9 months ago
I assume you're Pro, so the build timeout would be greater than 30 minutes, but at the same time, re-indexing shouldn't be done in a build step, you should have a seperate process (service) that runs the indexer.
Yes deployment 2 can access the same data as deployment 1, as long as the data is saved in the volume, that is the goal of volumes, data persistence across deployments, and if done correctly, you will not need to reindex everytime meiliseach is re-deployed.
Ok that latter point is I think what I need to get going - I will look at how to transfer data from volumes, appreciate it!
For now are there hooks we can do when services redeploy or is there any idea how often we expect it to happen on metal? Like I said it went 9 months without a deploy so wondering if this is going to be a common thing until we figure out how to transfer the search index data.
Thanks!
9 months ago
Data does not transfer from volumes, nor would you want it to, it stays in the volume, and any deploy for the service will have access to the data in the volume.
For a hook, you can use webhooks -
Appreciate your help, do you know if these templates are open source so I can see how they included these variables?
https://railway.com/new/template/meilisearch
Id like to include this database path in my current setup vs building out an entirely new service. Thanks!
9 months ago
You can click the 5 pre-configured environment variables accordion to see what variables the author has set.