I was looking forward for IaC solution for railway, but it feels like a step back from the original config-as-code.

I get the whole plan and apply, have been part of production teams, where we managed terraform + GCP resources combination, was hoping it would somewhat simplified version of it, but at the moment, it feels incomplete in a few important areas.

A few specific frustrations:

1. No way to provide custom docker registry credentials. I have my own docker private registry where I push my images to as part of github actions. Pre IaC error i used to create an empty service, connect an images and provide credentials as part of it. Now it feels like it gets stuck multiple times on first deploy, because credentials are not present, and I'm not able to provide credentials to the new service. If I have to manually create/update certain configuration through the dashboard while managing another subset of configuration through IaC, that somewhat defeats the original goal of having the infrastructure configuration represented as code.

2. The similar things with CPU limit and memory limit. With config as code it was easy with a cpuLimit and memoryLimit config. BTW had get this config keys from json schema, as it was not documented in railway's official docs.

3. Ambiguous/duplicated properties. Specifically around replicas and healthCheck. There is top level healthChecks properties and there is also run.healthCheck. Same for predeploy commands. I'm not sure which is the correct or idiomatic.

4. The partial feature looks useful, but I couldn't find documentation on how to reference or reuse common components/resources across services.

For example, I use a multi-tenant database setup across several small applications. I'd like to define that common infrastructure once and reference it from multiple services, rather than duplicating the configuration.

I couldn't find anything that explains whether this is supported, and if so, what the recommended/idiomatic approach is.

It also feels like IaC was made GA a little too soon, before some of these frustrating edge cases were addressed.

From my experience, config-as-code was already close to 90% complete for my use case. I could manage the majority of my applications entirely through code, and for the few things it didn't support, I could fall back to the Railway CLI.

With IaC, however, I'm finding that some configurations that were previously manageable through config-as-code are either missing, unclear, or require falling back to the dashboard. So for my particular use case, the new IaC experience currently feels like a regression in coverage rather than an improvement.