[GH-ISSUE #6052] Allow netbird expose to run in background and return URL programmatically #12036

Open
opened 2026-08-05 01:32:14 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @marcportabellaclotet-mt on GitHub (May 2, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/6052

Currently, the netbird expose command runs in the foreground and does not provide an easy way to integrate it into automation workflows.

This creates challenges when trying to:

  • Programmatically expose a service
  • Retrieve the generated public URL
  • Pass that URL to external systems (e.g., webhooks, CI pipelines, or notification services)

Because the process is blocking and not automation-friendly, it requires workarounds such as manual intervention, backgrounding hacks, or parsing logs, which are brittle and unreliable.


Describe the solution you'd like

I would like netbird expose to support a non-blocking / background mode and structured output.

For example:

  • Add a flag like --background or --detach to run the command in the background
  • Add a flag like --output json to return structured data including the exposed URL

Example usage:

netbird expose http 8080 --background --output json

Example output:

{
  "url": "https://xxxx.netbird.cloud",
  "status": "running"
}

This would allow:

  • Capturing the URL programmatically
  • Passing it to external services (APIs, CI/CD pipelines, chat notifications, etc.)
  • Building fully automated workflows around NetBird exposure

Describe alternatives you've considered

  • Running netbird expose in the background using shell tricks (&, nohup), but this does not solve structured output or lifecycle management

None of these approaches provide a clean or robust solution for automation.


Additional context

This feature would significantly improve NetBird’s usability in:

  • CI/CD pipelines
  • Kubernetes jobs / containers
  • Automation tools (e.g., scripts, workflows, orchestration systems)

It would enable use cases such as:

  • Automatically exposing a temporary service and notifying another system
  • Integrating NetBird exposure into testing or preview environments
  • Dynamic service exposure with external callbacks
Originally created by @marcportabellaclotet-mt on GitHub (May 2, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/6052 ### **Is your feature request related to a problem? Please describe.** Currently, the `netbird expose` command runs in the foreground and does not provide an easy way to integrate it into automation workflows. This creates challenges when trying to: * Programmatically expose a service * Retrieve the generated public URL * Pass that URL to external systems (e.g., webhooks, CI pipelines, or notification services) Because the process is blocking and not automation-friendly, it requires workarounds such as manual intervention, backgrounding hacks, or parsing logs, which are brittle and unreliable. --- ### **Describe the solution you'd like** I would like `netbird expose` to support a non-blocking / background mode and structured output. For example: * Add a flag like `--background` or `--detach` to run the command in the background * Add a flag like `--output json` to return structured data including the exposed URL Example usage: ```bash netbird expose http 8080 --background --output json ``` Example output: ```json { "url": "https://xxxx.netbird.cloud", "status": "running" } ``` This would allow: * Capturing the URL programmatically * Passing it to external services (APIs, CI/CD pipelines, chat notifications, etc.) * Building fully automated workflows around NetBird exposure --- ### **Describe alternatives you've considered** * Running `netbird expose` in the background using shell tricks (`&`, `nohup`), but this does not solve structured output or lifecycle management None of these approaches provide a clean or robust solution for automation. --- ### **Additional context** This feature would significantly improve NetBird’s usability in: * CI/CD pipelines * Kubernetes jobs / containers * Automation tools (e.g., scripts, workflows, orchestration systems) It would enable use cases such as: * Automatically exposing a temporary service and notifying another system * Integrating NetBird exposure into testing or preview environments * Dynamic service exposure with external callbacks
saavagebueno added the feature-request label 2026-08-05 01:32:14 -04:00
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#12036