ADK Hosted Runtime Strips .env and Does Not Inject MODEL_ACCESS_KEY

Heya,

You’ve diagnosed this correctly, and you’re not missing a flag. The ADK public preview doesn’t currently expose a secret-injection mechanism for the hosted runtime. If you read the docs closely, the .env step only ever wires up two things: your local gradient agent run testing, and the DIGITALOCEAN_API_TOKEN the CLI uses on your own machine at deploy time to create the workspace. Nothing in the flow actually documents how a variable in .env becomes a runtime environment variable inside the deployed /app process, and as you’ve confirmed empirically, it doesn’t. The file gets stripped from the release and nothing replaces it. So the supported mechanism you’re after isn’t hidden behind a flag, it just isn’t shipped yet in the preview.

Two things I’d do.

For an actual unblock today: the strip looks specific to .env itself, not your whole upload. Your own listing shows the rest of the application files are present in /app, so anything you bundle under a different filename survives. Instead of reading the model key from the environment, read it from a plain file you ship with the code, say a config.py constant or a secrets.json that main.py loads at startup. It’s not how you’d run this in production, since the key then lives inside the deployed image and should be treated as rotatable, but it gets a preview agent authenticating to inference today without waiting on the platform.

For a real fix and an authoritative answer: the Gradient ADK CLI is open source at github.com/digitalocean/gradient-adk. File exactly the diagnostic you posted here as an issue there. That reaches the people who own the runtime and CLI directly, and a clean repro like yours is the fastest route to either being told the intended mechanism or getting it prioritized. It’ll do better than the support queue, which as you saw macro’d your ticket. If you keep the ticket open in parallel, label it plainly as “Gradient ADK hosted runtime does not inject env vars, public preview” so it routes to the right team instead of the SMTP macro again.

Heya,

One thing worth adding to the GitHub issue when you file it: DigitalOcean’s own docs are inconsistent on the variable name itself, some reference GRADIENT_MODEL_ACCESS_KEY and others just MODEL_ACCESS_KEY for the same purpose, so it’s not just your app that’s confused. Worth flagging that alongside the missing injection mechanism, it makes the bug report stronger.

Also worth a quick check before you commit to bundling secrets in code: DigitalOcean’s Gradient Deployments product, which ADK sits on top of, does document a real deployment secrets mechanism using secret:mySecretValue syntax in the deployment spec. I can’t confirm that actually reaches ADK’s hosted runtime specifically, the preview clearly doesn’t expose it through the CLI or workspace UI yet, but it’s worth asking directly in the GitHub issue whether that spec-level mechanism is meant to work here or is genuinely absent for ADK, rather than assuming it’s a dead end.

Regards

You’ve narrowed this down well. Since .env is uploaded but removed at runtime, it’s likely the platform expects secrets to be injected through a supported secret manager or runtime configuration instead. The ADK preview docs/support team should confirm the exact mechanism, as the current CLI/UI options don’t expose one.