Publishing Services

Expose web applications and terminals from your nodes to the internet with public HTTPS URLs. No port forwarding, no reverse proxy configuration, no SSL certificates to manage.

Overview

Service publishing in noBGP creates secure, public endpoints for:

• Web applications running on your nodes (Proxy Services)
• Browser-based terminals for remote access (Terminal Services)

All published services get:

• Unique HTTPS URLs (e.g., https://abc123.nobgp.com)
• Valid SSL/TLS certificates (automatic)
• Optional OAuth authentication
• Enable/disable without deleting
• Real-time analytics

Service Types

Proxy Services

Route public traffic to HTTP applications running on your nodes.

Use cases:

• Share a development web app with teammates
• Expose an internal dashboard temporarily
• Demo an application to clients
• Access a private admin panel remotely

Example flow:

Terminal Services

Provide browser-based shell access to your nodes.

Use cases:

• Remote administration without SSH
• Share a terminal session with teammates
• Emergency access when SSH is unavailable
• Access air-gapped or NAT'd systems

Example flow:

Publishing a Proxy Service

Basic Proxy

To expose a web app running on port 8080:

Publish my web app running on localhost:8080 from my-server

Your AI assistant will:

1. Create a service targeting http://localhost:8080
2. Generate a unique public URL
3. Configure HTTPS with valid certificates
4. Return the URL to you

Response Example

AI: I've published your web app as a proxy service.

    Service URL: https://a1b2c3d4.nobgp.com
    Target: http://localhost:8080 on my-server
    Authentication: Required (OAuth)
    Status: Enabled

    Anyone with access to your network can now visit this URL and access your
    web app after signing in.

Specifying Target URLs

You can specify different targets:

Publish port 3000 from api-server as a public service

or more specifically:

Create a proxy service for http://127.0.0.1:9000/admin on web-server-1

The AI understands various formats:

• localhost:8080
• http://localhost:8080
• http://127.0.0.1:3000/path
• 0.0.0.0:9000

Authentication Options

By default, services require OAuth authentication. You can make them public:

Publish my app on port 8080 as a public service (no auth required)

or explicitly require auth:

Publish my admin panel with authentication required

Security

Public services (no auth) can be accessed by anyone with the URL. Only use for demos or truly public applications.

Publishing a Terminal Service

Basic Terminal

To create a browser terminal for a node:

Create a browser terminal for my-server

or

Publish a web terminal for raspberry-pi with auth required

Response Example

AI: I've created a browser-based terminal for my-server.

    Terminal URL: https://x9y8z7w6.nobgp.com
    Authentication: Required (OAuth)
    Status: Enabled

    Open this URL in your browser to access an interactive shell on my-server.
    You'll need to sign in before accessing the terminal.

Using the Terminal

Once you open the URL:

1. Sign in with OAuth (if required)
2. You'll see a full terminal interface
3. Type commands as if you were SSH'd in
4. Full support for colors, cursor movement, interactive programs

Terminal Features

Browser terminals support:

• Interactive programs: vim, nano, htop, less, etc.
• Control characters: Ctrl+C, Ctrl+D, Ctrl+L, Ctrl+Z
• Arrow keys: Navigate command history
• Tab completion: Works with bash/zsh completion
• Resize: Automatically adapts to browser window size
• Copy/paste: Standard browser shortcuts

Managing Services

Listing Services

See all your published services:

Show me all my published services

or for a specific node:

What services are published from api-server?

Updating Services

You can modify service settings:

Make the service abc123 public (remove authentication)

or

Update service xyz789 to require authentication

Disabling/Enabling Services

Temporarily disable without deleting:

Disable the service at abc123.nobgp.com

Re-enable later:

Enable the service abc123 again

tip

Disabling a service keeps the URL and configuration but makes it inaccessible. This is useful for temporary shutdowns without losing the URL.

Deleting Services

Permanently remove a service:

Delete the service abc123

or

Remove all services from my-server

The AI will confirm before deleting.

Advanced Usage

Multiple Services Per Node

You can publish multiple services from the same node:

You: Publish port 8080 from my-server as "app"
AI: ✓ Service created: https://app1.nobgp.com

You: Also publish port 9000 from the same server as "api"
AI: ✓ Service created: https://api2.nobgp.com

Each service gets its own unique URL.

Service Names

Give services memorable names:

Publish my web app on port 8080 and call it "staging-app"

Later you can reference it by name:

Disable the staging-app service

Custom Paths

Proxy services can target specific paths:

Publish http://localhost:8080/api from my-server

Requests to https://abc123.nobgp.com/anything will go to http://localhost:8080/api/anything.

WebSocket Support

Proxy services fully support WebSocket connections, so real-time apps work seamlessly:

Publish my React app with hot-reload on port 3000

The development server's WebSocket for hot-reload will work through the proxy.

Security Best Practices

1. Use Authentication for Sensitive Services

Always require OAuth for:

• Admin panels
• Internal tools
• APIs with sensitive data
• Database management interfaces

Publish my admin panel with authentication required

2. Limit Service Lifespan

For demos or temporary access:

You: Publish my app on port 8080 as public for the demo
[Give demo]
You: Delete that service now

3. Monitor Access

Check your published services regularly:

Show me all public services (no auth required)

4. Use Strong Target Security

Just because a service requires OAuth doesn't mean the underlying app should be insecure:

• Still use HTTPS in your app if possible
• Implement application-level authentication
• Validate all inputs
• Follow security best practices

5. Rotate URLs Periodically

For long-running public services, periodically rotate:

Delete service abc123
Publish my app again to get a new URL

Common Patterns

Development Workflow

Share work-in-progress with teammates:

You: I need to share my local dev server with the team

AI: I'll publish it as a service with auth required...
    ✓ https://dev1.nobgp.com (OAuth required)

    Share this URL with your teammates. They'll need to sign in with their
    noBGP accounts to access it.

Demo to Clients

Temporarily expose an app:

You: Publish my demo app on port 8080 as public (client demo)

AI: ✓ https://demo1.nobgp.com (public, no auth)

[After demo]

You: Delete the demo service

AI: ✓ Service deleted

Raspberry Pi Access

Access your Pi's web interfaces:

You: Publish the Pi-hole admin interface from my raspberry-pi

AI: ✓ https://pihole1.nobgp.com (OAuth required)

    Access your Pi-hole dashboard from anywhere!

Remote Administration

Terminal access from anywhere:

You: Create a browser terminal for all my production servers

AI: Creating terminals...
    ✓ prod-web-1: https://term1.nobgp.com
    ✓ prod-api-1: https://term2.nobgp.com
    ✓ prod-db-1: https://term3.nobgp.com

    All terminals require OAuth authentication.

Troubleshooting

Service Returns 404

Issue: Opening the service URL shows "Not Found"

Solutions:

• Wait 30-60 seconds for DNS propagation
• Verify service is enabled: "Show me service abc123 status"
• Check target application is running: "Run 'curl localhost:8080' on my-server"
• Verify target port is correct

Service Returns 502 Bad Gateway

Issue: Service URL loads but shows gateway error

Solutions:

• Confirm target application is running
• Check target port: "What's listening on port 8080 on my-server?"
• Verify target URL format (should be http:// not https://)
• Check application logs

Can't Access Service (403 Forbidden)

Issue: Service requires authentication but can't sign in

Solutions:

• Ensure you're signed into a noBGP account
• Check you have access to the network the node belongs to
• Try signing out and back in
• Verify OAuth provider is working

Terminal Doesn't Respond

Issue: Browser terminal loads but doesn't show prompt or accept input

Solutions:

• Refresh the page
• Check node is still online: "Show me my-server status"
• Disable/re-enable the service
• Try creating a new terminal service

WebSocket Connection Failed

Issue: App works but real-time features don't

Solutions:

• Verify your app uses relative WebSocket URLs (not absolute)
• Check firewall settings on the node
• Ensure WebSocket connections aren't blocked by browser extensions
• Try a different browser

Limits and Quotas

Limit Type	Default	Notes
Services per node	10	Contact support to increase
Total services	50	Across all nodes
Concurrent connections per service	100	For terminal services

Check your usage:

How many services do I have published?

Next Steps

• Interactive Terminals Guide - Deep dive into terminal features
• Use Cases & Examples - Real-world service publishing scenarios
• Core Concepts - Understand service architecture

FAQ

Q: Do service URLs ever change? A: No, once created, a service URL remains the same until you delete the service.

Q: Can I use custom domains? A: Not currently. Custom domain support is on the roadmap.

Q: What happens if my node goes offline? A: The service URL remains but will return errors until the node comes back online.

Q: Can I publish services from provisioned nodes? A: Yes! Provisioned nodes work exactly the same as agent-installed nodes.

Q: Is there a bandwidth limit? A: Services have reasonable bandwidth limits. Contact support if you need higher limits.

Q: Can I publish HTTPS apps? A: Target URLs should be HTTP. The public service URL is always HTTPS automatically.

Q: How long do terminal sessions last? A: Browser terminal sessions timeout after 30 minutes of inactivity.

Q: Can multiple people use the same terminal service URL? A: Yes, but they'll each get separate shell sessions.