A Pro plan is only another separate workspace under your main account, your main account can be on the Hobby plan or the trial plan, for you to "downgrade" to the Hobby plan you must first make sure your main account is on the Hobby plan. Once that is done you can transfer all the needed projects from the Pro workspace to the Hobby workspace via their project settings page. Then you may cancel the Pro workspace.

I upgraded to the Pro plan for the increased resource limits (32vCPU/memory) but no longer need the increased limits as that part of the app has been moved off of Railway.

I would very much appreciate it if you could elaborate on this, why was Railway not a good fit for what you moved off?

For the record, commercial use must be on the Pro plan. Can you elaborate more on not utilizing the limits?

Sure, happy to elaborate. I was running a bioinformatics pipeline for an internal tool and would consistently hit the errors below:
java -ea -XX:+ExitOnOutOfMemoryError

[E::hts_tpool_init] Couldn't start thread pool worker : Resource temporarily unavailable

Exception in thread "main" java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached

at java.base/java.lang.Thread.start0(Native Method)

at java.base/java.lang.Thread.start(Thread.java:1513)

at stream.ConcurrentGenericReadOutputStream.start(ConcurrentGenericReadOutputStream.java:60)

at jgi.BBDuk.spawnProcessThreads(BBDuk.java:1960)

at jgi.BBDuk.process2(BBDuk.java:1225)

at jgi.BBDuk.process(BBDuk.java:1121)

at jgi.BBDuk.main(BBDuk.java:81)

[0.192s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 4k, detached.

Error occurred during initialization of VM

Tried many different things to fix it but no dice. Then I tried the same code/image in ECS and it worked fine (even with less resources available), so I migrated the job processor to AWS. Additionally, in Railway I had to setup a the job processor as a polling mechanism to pick up pipeline jobs and process them concurrently on one service. By using ECS I was able to set it up so that a new task is created for every pipeline run and deallocated upon completion. This way jobs run independently and it's practically infinitely scalable. I'm not sure if this is possible in Railway.

I've kept the other parts on Railway as the Github integration and automatic builds save a ton of setup time. I do really enjoy Railway (super easy setup) and always try to use it first but it seems that a java-based bioinformatics job processor isn't a good fit for the platform just yet.

Thank you for the feedback, we really appreciate it! And we're glad that you do enjoy Railway for your other workflows.

For the java-based bioinformatics job processor, did you need more than 32 GB memory?

I thought it needed more than 32gb of memory (that's why I upgraded to Pro) but it's able to run in AWS even with only 4gb of memory, just takes longer to process so I give it the max memory that Fargate allows. I think there's some weird interaction between the code and the VM in Railway that causes it to try to use more resources than is available and just crashes the process. I don't have that issue using Fargate, runs fine even though it'll completely max out the vCPUs for a good 20 minutes but never crashes. In the Railway job processor, I setup a logger to log the available resources every 5 seconds but didn't find anything actionable.

I spent a lot of time trying to figure out how to fix it and get it working in Railway but ultimately it was easier to just switch that part of the tool to AWS.

For reference, I'm using a custom dockerfile and pulling from "continuumio/miniconda3". It installs a few linux packages and a bunch of informatics packages using conda. The total images size is ~7.85gb. I use python to invoke a shell script that starts a snakemake workflow for each job. Within seconds, it'll throw the error that's in a previous message in this thread.

Thank you for the feedback and additional context. We're taking this into consideration as we evolve the platform going forward.