can't get railway.json - RAILPACK - deploy - aptPackages working
smidm
PROOP

4 months ago

The aptPackages section of railway.json is ignored. I don't see the packages in the merged build configuration:

{
  "$schema": "https://railway.com/railway.schema.json",
  "build": {
    "builder": "RAILPACK"
  },
  "deploy": {
    "runtime": "V2",
    "numReplicas": 1,
    "startCommand": "uv run uvicorn app.app:app --host 0.0.0.0 --log-level debug --port \"$PORT\"",
    "healthcheckPath": "/health",
    "sleepApplication": true,
    "useLegacyStacker": false,
    "multiRegionConfig": {
      "europe-west4-drams3a": {
        "numReplicas": 1
      }
    },
    "restartPolicyType": "ON_FAILURE",
    "restartPolicyMaxRetries": 10
  }
}

When using RAILPACK_DEPLOY_APT_PACKAGES it works well, but I want the deployment to be defined in the sources.

The build configuration corresponds to the main branch railway.json where is no aptPackages section.

my railway.json :

{

  "$schema": "https://railway.app/railway.schema.json",

  "build": {

    "builder": "RAILPACK"

  },  

  "deploy": {

    "aptPackages": [

      "libmagic-dev",

      "ffmpeg"

    ],

    "startCommand": "uv run uvicorn app.app:app --host 0.0.0.0 --log-level debug --port \"$PORT\"",

    "healthcheckPath": "/health"

  }

}
Solved$10 Bounty

Pinned Solution

4 months ago

I don't think you can use aptPackages there, I'm pretty sure those need to go in a railpack configuration file. I think easiest would be to remove the apt packages configuration from your railway.json and instead use aRAILPACK_DEPLOY_APT_PACKAGES (or RAILPACK_BUILD_APT_PACKAGES if you need it during build) service variable for which packages Railpack should install.

This is generally recommended over a custom railpack configuration file because it loses out on optimizations railpack makes, but if you want to you could also just use a railpack configuration file instead. I recommend the service variable approach instead though

4 Replies

Railway
BOT

4 months ago

Hey there! We've found the following might help you get unblocked faster:

If you find the answer from one of these, please let us know by solving the thread!


4 months ago

I don't think you can use aptPackages there, I'm pretty sure those need to go in a railpack configuration file. I think easiest would be to remove the apt packages configuration from your railway.json and instead use aRAILPACK_DEPLOY_APT_PACKAGES (or RAILPACK_BUILD_APT_PACKAGES if you need it during build) service variable for which packages Railpack should install.

This is generally recommended over a custom railpack configuration file because it loses out on optimizations railpack makes, but if you want to you could also just use a railpack configuration file instead. I recommend the service variable approach instead though


dev

I don't think you can use aptPackages there, I'm pretty sure those need to go in a railpack configuration file. I think easiest would be to remove the apt packages configuration from your railway.json and instead use aRAILPACK_DEPLOY_APT_PACKAGES (or RAILPACK_BUILD_APT_PACKAGES if you need it during build) service variable for which packages Railpack should install.This is generally recommended over a custom railpack configuration file because it loses out on optimizations railpack makes, but if you want to you could also just use a railpack configuration file instead. I recommend the service variable approach instead though

smidm
PROOP

4 months ago

Thanks, the schemas of railway.json and railpack.json are similar and I got confused. I moved the deploy configuration to railpack.json and it's working now. Do you have some docs supporting the optimization claim? From what I have read it seems equivalent.


4 months ago

I'm glad that helped

My claim isn't from the docs, I heard it from a Railway employee, JR. I doubt it's anything to worry about though, it's just between service variable configuration and configuration files, service variables would be the more optimal choice.


Status changed to Solved noahd 4 months ago


Loading...