ADK Hosted Runtime Strips .env and Does Not Inject MODEL_ACCESS_KEY

Question

I completed an additional hosted-runtime path diagnostic.

The hosted process reports:

cwd: /app entrypoint_file: /app/main.py entrypoint_dir: /app

The /app directory listing contains the deployed application files but does not contain .env.

Results:

cwd_dotenv_present: false entrypoint_dotenv_present: false dotenv_loaded: false CUSTOMKEY_CANARY: false DIGITALOCEAN_INFERENCE_KEY: false GRADIENT_MODEL_ACCESS_KEY: false MODEL_ACCESS_KEY: false

This eliminates the possibility that the agent is running from a different directory.

The Gradient CLI verbose deployment log confirms that .env was added to staging.zip and uploaded successfully, but the hosted release removes the file and does not convert any of its variables into runtime environment variables.

Please provide the supported secret-injection mechanism for the current ADK public-preview runtime and CLI. The current CLI has no --env option, and the ADK workspace UI has no Environment Variables section.

mallamace · Accepted Answer

MrDiggles2 on Github: “FWIW, I ran into this and found that it was an interaction with .dockerignore. After removing .env from .dockerignore, gradient agent deploy worked fine. Using version 0.2.12” https://github.com/digitalocean/gradient-adk/issues/48 This resolved the issue.

KFSys · Answer

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.

alexdo · Answer

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

Become a contributor for community

DigitalOcean Documentation

Resources for startups and AI-native businesses

The developer cloud

Start building today

Report this

ADK Hosted Runtime Strips .env and Does Not Inject MODEL_ACCESS_KEY

Related questions

What are the best AI frameworks and tools for adding AI features to mobile apps?

What API mocking tool is your team using?

Please enable General Purpose and Memory-Optimized droplet access

How much you're spending on AI tools?

How do I disable AI?

When will OpenSearch v3 be available on DigitalOcean Managed Databases?

How can developers build a scalable video streaming solution using DigitalOcean?

What’s your typical stack for launching a startup on DigitalOcean?

Choice of models limited

Problems with the OpenClaw droplet

Moltbot/Clawdbot/Open Claw security

how to enable SMTP on server for zoho mail587 and 465

Report this

ADK Hosted Runtime Strips .env and Does Not Inject MODEL_ACCESS_KEY

Related questions

What are the best AI frameworks and tools for adding AI features to mobile apps?

What API mocking tool is your team using?

Please enable General Purpose and Memory-Optimized droplet access

How much you're spending on AI tools?

How do I disable AI?

When will OpenSearch v3 be available on DigitalOcean Managed Databases?

How can developers build a scalable video streaming solution using DigitalOcean?

What’s your typical stack for launching a startup on DigitalOcean?

Choice of models limited

Problems with the OpenClaw droplet

Moltbot/Clawdbot/Open Claw security

how to enable SMTP on server for zoho mail587 and 465