Feature Requests

[hard-nett]

Just wanted to open up some ideas for features to expand the possible use-cases of cosmos omnibus. Would love any feedback or additional ideas!

1. Support to update ENV variables without restarting deployment

I imagine a design where if a public key is provided initially on deployment, that this public key could broadcast a signed message to the service containing environment variables to be updated. This would mitigate nodes restarting as if they were just deployed, cutting provider load and improving throughput as well as state retention.

2. Caddy Support For Hosting Snapshots Directly

A caddy server & UI exposed to port 80 for displaying & accessing all snapshots for a node. This would not conflict with existing snapshot exporting features.

---

updated: 2026/02/21

3. TLS support for Nodes

Adding a native design to the entrypoint script for installation & configuration of a reverse proxy shell and defining the correct cert & key paths for https support would enhance security for users communicating/ using deployed nodes.

Right now im experimenting with this and using a custom START_CMD script that downloads a script and performs the functions before starting a node, however having this native would reduce complexity and trust assumptions

4. Snapshot Granularity

env flags can enable/disable additional data snapshots and exported to s3 bucked such as:

• addrbook.json
• compressed folder of wasm state

[tombeynon]

Nice ideas. Some thoughts below:

1. Updating ENV vars without restarting deployment. This would be tricky to implement, as it would also require restarting the node software after an ENV var was updated, so would need a cosmovisor style runner to monitor the vars and restart. I wonder how useful this really is, especially now persistent storage is generally available?
2. I think this is best implemented as a 'sidecar' style container, rather than building into Omnibus directly. Something like FileBrowser should work.

[hard-nett]

Nice ideas. Some thoughts below:

1. Updating ENV vars without restarting deployment. This would be tricky to implement, as it would also require restarting the node software after an ENV var was updated, so would need a cosmovisor style runner to monitor the vars and restart. I wonder how useful this really is, especially now persistent storage is generally available?

maybe adding support for ssh into a node (opt-in) could power this feature, where there is a pre-existing script to temporarily halt the daemon service, apply new env variables in the shell (overwriting the existing ones) and then resuming the service. wdyt?

a script available would pair well with https://akash.network/docs/learn/core-concepts/shell-access/#interactive-shell-access

[hard-nett]

2. I think this is best implemented as a 'sidecar' style container, rather than building into Omnibus directly. Something like FileBrowser should work.

Took your suggestion and implemented a demo that makes use of filebrowser using an s6-overlay to add support for IPFS gateway pinning & s3 bucket api capabilities!

Since filebrowser (go version) doesnt support native s3 api calls, pivoted to replacing it with Minio, which includes a gui as well as s3 compatible api to work with existing logic: https://github.com/permissionlessweb/o-line/pkgs/container/minio-ipfs