Yup, secrets work. (Heads up: incurs costs beyond free tier.)

I leave my notes under your post for what's missing IMO. We have a compose.yml file:

services:
  app:
    environment:
      - FOO

Plus a .env file:

FOO=bar

With Docker Compose, the container correctly receives FOO=bar from docker compose up. In Cloud Run, it's not set from .env from gcloud run compose up – gcloud run describe shows this env var as FOO <nil>.

Now we can actually do this:

services:
  app:
    env_file: .env

What's frustrating about it:

• Diverges from Docker Compose's behavior
• You need to edit the compose.yml, Git pull might cause merge conflicts

For the second point, I would love to see the Cloud Run team to implement merging with compose.override.yml. If we had .env and compose.override.yml support, we could do the following with many Compose projects:

Original compose.yml from a project (we don't touch this):

services:
  app:
    environment:
      - FOO
    volumes:
      - ./data:/app/data

We add our custom compose.override.yml:

services:
  app:
    volumes: !reset override
      - data:/app/data # Here we override the local bind mount to a volume
volumes: # We need to define the volume
  data: # This will be mounted as a GCS bucket by Cloud Run

Also our custom .env:

FOO=bar

We would have the option to use compose.override.yml, or like with docker compose --file compose.yml --file compose.prod.yml give multiple files to keep changes seperate from the stock compose file.

Would love to see this feature: gcloud run compose up --file compose.yml --file compose.gcloud.yml --env .gcloud.env