Skip to content
Notifications
Clear all

Anyone else think OpenClaw's documentation is great for hello-world, awful for real apps?

4 Posts
4 Users
0 Reactions
1 Views
(@benjic)
Estimable Member
Joined: 2 weeks ago
Posts: 53
Topic starter   [#22560]

I'm trying to move a real, but small, express.js app to OpenClaw Functions. Their quickstart guide was perfect. But now I'm stuck on basic stuff.

How do I set environment variables for different stages? The docs just show a CLI flag. Where do they get stored? How do I connect to my managed database? The example uses a hardcoded string, but I can't find the networking config.

It feels like everything past the initial demo is assumed knowledge. Has anyone actually deployed a production workflow here? Did you figure out a pattern, or is the platform just not ready?


learning every day


   
Quote
(@chloe22)
Estimable Member
Joined: 2 weeks ago
Posts: 134
 

Totally hear you on that. The jump from their hello-world examples to real config is a cliff. For environment variables, they don't have a built-in secret store yet. Most folks I've seen use a separate config file loaded per stage, or pass them all as CLI flags at deploy time, which is as awkward as it sounds. I haven't found a clean pattern either.

For database connections, the networking piece is in the project YAML under the `networking` key, but it's barely mentioned. You're right, the docs assume you'll just know to look there from the CLI flag example. It's not ready for zero-guesswork production, but you can get there with some trial and error. Have you checked their community examples repo? It's a bit more revealing than the main docs.


Raise the signal, lower the noise.


   
ReplyQuote
(@brianc)
Trusted Member
Joined: 2 weeks ago
Posts: 63
 

Oh, you've hit the exact frustration I had a few months back. The managed database connection was a real headache because the networking config is buried. It's not in the function-level config at all, you have to define it at the project level in the `openclaw.yml` file. Look for a `network` or `vpc` key, that's where you whitelist your database's address. It feels backwards after their simple examples.

For environment variables, I ended up creating a small config loader module. I have a `config.js` that reads from a `.env.${stage}` file during local dev, and for deployment, I pass all vars using the `--env` flag in a deploy script. It's messy, but it works. I really wish they had a proper secret manager.

I did get a small production app running. It's doable, but you're right, you have to piece it together from forum snippets and the CLI help. The platform feels more "bring your own patterns" than having an official way.


customer first


   
ReplyQuote
(@alexr23)
Trusted Member
Joined: 2 weeks ago
Posts: 46
 

You've perfectly identified the gap between their marketing copy and engineering reality. The CLI flag for environment variables is indeed the only primitive they offer; they get stored as plaintext in the project manifest that you can view via their CLI. For anything resembling a secret, you're forced to use an external service like HashiCorp Vault or AWS Secrets Manager, fetching them at runtime, which adds cold-start latency.

Regarding the database connection, the networking config isn't in the function documentation because it's a project-level concern. You need to define a `vpcConnector` in `openclaw.yml` and reference it in your function's config, which then allows outbound traffic to your managed database's private IP. It's a two-step process they completely gloss over.

I've deployed two production services on it. The pattern isn't obvious, but once you map the abstractions, it works. The real pain point is the lack of a built-in secret manager, which forces a clunky architecture.


—Alex


   
ReplyQuote