Standardize CLI flag usage ('=' vs ' ')

docs/agent/cli.mdx

@@ -33,7 +33,7 @@ ngrok http --url baz.ngrok.dev 8080     # port 8080 available at baz.ngrok.dev
 ngrok http foo.dev:80                   # tunnel to host:port instead of localhost
 ngrok http https://localhost            # expose a local https server
 ngrok tcp 22                            # tunnel arbitrary TCP traffic to port 22
-ngrok tls --url=foo.com 443             # TLS traffic for foo.com to port 443
+ngrok tls --url foo.com 443             # TLS traffic for foo.com to port 443
 ngrok start foo bar baz                 # start tunnels from the configuration file
 ```
 
@@ -360,10 +360,10 @@ ngrok http [address:port | port] [flags]
 ```sh
 ngrok http 8080                             # forward ngrok subdomain to port 80
 ngrok http example.com:9000                 # forward traffic to example.com:9000
-ngrok http --url=bar.ngrok.dev 80           # request url name: 'bar.ngrok.dev'
-ngrok http --url=example.com 1234           # request endpoint 'example.com' (DNS CNAME)
-ngrok http --basic-auth='falken:joshua' 80  # enforce basic auth on tunnel endpoint
-ngrok http --host-header=example.com 80     # rewrite the Host header to 'example.com'
+ngrok http --url bar.ngrok.dev 80           # request url name: 'bar.ngrok.dev'
+ngrok http --url example.com 1234           # request endpoint 'example.com' (DNS CNAME)
+ngrok http --basic-auth 'falken:joshua' 80  # enforce basic auth on tunnel endpoint
+ngrok http --host-header example.com 80     # rewrite the Host header to 'example.com'
 ngrok http file:///var/log                  # serve local files in /var/log
 ngrok http https://localhost:8443           # forward to a local https server
 ```
@@ -514,7 +514,7 @@ ngrok tcp [address:port | port] [flags]
 ngrok tcp 22
 
 # expose an RDP server on a specific public address that you reserved
-ngrok tcp --url=1.tcp.ngrok.io:27210 3389
+ngrok tcp --url 1.tcp.ngrok.io:27210 3389
 ```
 
 ### Flags
@@ -564,13 +564,13 @@ ngrok tls [address:port | port] [flags]
 
 ```sh
 # forward TLS traffic for example.com to port 443 (requires CNAME)
-ngrok tls --url=example.com 443
+ngrok tls --url example.com 443
 
 # forward TLS traffic on subdomain (mismatch certificate warning)
 ngrok tls 1234
 
 # terminate TLS traffic for t.co before forwarding
-ngrok tls --url=t.co --crt=/path/to/t.co.crt --key=/path/to/t.co.key 443
+ngrok tls --url t.co --crt /path/to/t.co.crt --key /path/to/t.co.key 443
 ```
 
 ### Flags
@@ -670,7 +670,7 @@ ngrok update [flags]
 
 ```sh
 ngrok update                     - update ngrok to the latest stable version
-ngrok update --channel=beta      - update ngrok to the latest beta version
+ngrok update --channel beta      - update ngrok to the latest beta version
 ```
 
 ### Flags

docs/getting-started/index.mdx

@@ -129,7 +129,7 @@ account is `alan@example.com`, you can restrict access only for yourself by
 running ngrok with:
 
 ```
-ngrok http http://localhost:8080 --oauth=google --oauth-allow-email=alan@example.com
+ngrok http http://localhost:8080 --oauth google --oauth-allow-email alan@example.com
 ```
 
 Anyone accessing your app will be prompted to log in with Google and only your

docs/guides/api-gateway/get-started.mdx

@@ -66,7 +66,7 @@ npm run start
 Create an internal endpoint for one of the instances of the API by running the following command:
 
 ```bash
-ngrok http 8001 --url=https://api.internal
+ngrok http 8001 --url https://api.internal
 ```
 
 ## Reserve a domain
@@ -214,8 +214,8 @@ You can configure traffic policy rules to direct traffic based on HTTP header va
 To implement this example, run each of the following commands in a separate terminal to start internal endpoints to the two instances of the sample API:
 
 ```bash
-ngrok http 8001 --url=https://v1.api.internal
-ngrok http 8002 --url=https://v2.api.internal
+ngrok http 8001 --url https://v1.api.internal
+ngrok http 8002 --url https://v2.api.internal
 ```
 
 While these endpoints point to two separate instances of the same backend API, they simulate the scenario where you need to direct traffic to two
@@ -343,8 +343,8 @@ Path-based routing enables you to direct traffic to different backend services b
 To implement this example, run the following commands in separate terminals to start internal endpoints to the two instances of the sample API:
 
 ```bash
-ngrok http 8001 --url=https://hostA.api.internal
-ngrok http 8002 --url=https://hostB.api.internal
+ngrok http 8001 --url https://hostA.api.internal
+ngrok http 8002 --url https://hostB.api.internal
 ```
 
 While these endpoints point to two separate instances of the same backend API, they simulate the scenario where you need to direct
@@ -415,7 +415,7 @@ without exposing internal system details.
 Run the following command to start an internal endpoint:
 
 ```bash
-ngrok http 8001 --url=https://api.internal
+ngrok http 8001 --url https://api.internal
 ```
 
 #### Update your policy rules
@@ -467,7 +467,7 @@ that each of your clients has fair access to your API.
 Run the following command to start an internal endpoint:
 
 ```bash
-ngrok http 8001 --url=https://api.internal
+ngrok http 8001 --url https://api.internal
 ```
 
 #### Update your policy rules
@@ -558,7 +558,7 @@ generate one.
 Run the following command to start an internal endpoint:
 
 ```bash
-ngrok http 8001 --url=https://api.internal
+ngrok http 8001 --url https://api.internal
 ```
 
 #### Update your policy rules

docs/guides/other-guides/how-to-set-up-a-custom-domain.mdx

@@ -59,7 +59,7 @@ Address: 203.0.113.94
 Once your DNS record is in place you can create a tunnel using your new domain. Try running:
 
 ```bash
-ngrok http --url=foo.example.com 8080
+ngrok http --url foo.example.com 8080
 ```
 
 and presuming you're actually running an application on port 8080 then making an HTTP request to `https://foo.example.com` should return a response from your app.

docs/integrations/curity/sso-oidc.mdx

@@ -113,10 +113,10 @@ ngrok can leverage Curity Identity Server in two ways:
 1. Enter the following command to launch an ngrok tunnel with Curity Identity Server. Replace `<curity_url>` with your Curity issuer address (i.e., https://acme.com/oauth/v2/oauth-anonymous) and the `<curity_client_id>` and `<curity_client_secret>` with the respective values copied from the ngrok app registered at Curity:
 
    ```bash
-   ngrok http 3000 --oidc=<curity_url> \
-   --oidc-client-id=<curity_client_id> \
-   --oidc-client-secret=<curity_client_secret> \
-   --url=curity-sso-test.ngrok.dev
+   ngrok http 3000 --oidc <curity_url> \
+   --oidc-client-id <curity_client_id> \
+   --oidc-client-secret <curity_client_secret> \
+   --url curity-sso-test.ngrok.dev
    ```
 
 1. [Skip to **Step 4**: ](#test-sso) Test the integration

docs/integrations/fusionauth/sso-oidc.mdx

@@ -70,10 +70,10 @@ ngrok can leverage FusionAuth SSO in two ways:
 1. Enter the following command to launch an ngrok tunnel with FusionAuth SSO. Replace `<FusionAuth_url>` with your FusionAuth org address (i.e., https://acme.fusionauth.com) and the `<FusionAuth_client_id>` and `<FusionAuth_client_secret>` with the respective values copied from the ngrok app registered at FusionAuth:
 
    ```bash
-   ngrok http 3000 --oidc=<FusionAuth_url> \
-   --oidc-client-id=<FusionAuth_client_id> \
-   --oidc-client-secret=<FusionAuth_client_secret> \
-   --url=fusionauth-sso-test.ngrok.dev
+   ngrok http 3000 --oidc <FusionAuth_url> \
+   --oidc-client-id <FusionAuth_client_id> \
+   --oidc-client-secret <FusionAuth_client_secret> \
+   --url fusionauth-sso-test.ngrok.dev
    ```
 
 1. Skip to **Step 3**

docs/integrations/okta/sso-oidc.mdx

@@ -81,10 +81,10 @@ ngrok can leverage Okta SSO in two ways:
 1. Enter the following command to launch an ngrok tunnel with Okta SSO. Replace `<okta_url>` with your okta org address (i.e., https://acme.okta.com) and the `<okta_client_id>` and `<okta_client_secret>` with the respective values copied from the ngrok app registered at Okta. Optionally, add the `--url <domain>` argument to get your own custom URL, replacing `<domain>` with your URL of preference:
 
    ```bash
-   ngrok http 3000 --oidc=<okta_url> \
-   --oidc-client-id=<okta_client_id> \
-   --oidc-client-secret=<okta_client_secret> \
-   --url=<domain>
+   ngrok http 3000 --oidc <okta_url> \
+   --oidc-client-id <okta_client_id> \
+   --oidc-client-secret <okta_client_secret> \
+   --url <domain>
    ```
 
 1. Copy the url available next to **Forwarding** (for example, `https://okta-sso-test.ngrok.dev`).

docs/using-ngrok-with/docker.md

@@ -14,11 +14,11 @@ Note: the Docker version of ngrok follows the same convention as the agent, for
 
 ```bash
 docker run -it -e NGROK_AUTHTOKEN=xyz ngrok/ngrok:latest http 80                            # secure public URL for port 80 web server
-docker run -it -e NGROK_AUTHTOKEN=xyz ngrok/ngrok:latest http --url=baz.ngrok.dev 8080   # port 8080 available at baz.ngrok.dev
+docker run -it -e NGROK_AUTHTOKEN=xyz ngrok/ngrok:latest http --url baz.ngrok.dev 8080   # port 8080 available at baz.ngrok.dev
 docker run -it -e NGROK_AUTHTOKEN=xyz ngrok/ngrok:latest http foo.dev:80                    # tunnel to host:port instead of localhost
 docker run -it -e NGROK_AUTHTOKEN=xyz ngrok/ngrok:latest http https://localhost:5001        # expose a local https server running on port 5001
 docker run -it -e NGROK_AUTHTOKEN=xyz ngrok/ngrok:latest tcp 22                             # tunnel arbitrary TCP traffic to port 22
-docker run -it -e NGROK_AUTHTOKEN=xyz ngrok/ngrok:latest tls --url=foo.com 443           # TLS traffic for foo.com to port 443
+docker run -it -e NGROK_AUTHTOKEN=xyz ngrok/ngrok:latest tls --url foo.com 443           # TLS traffic for foo.com to port 443
 docker run -it -e NGROK_AUTHTOKEN=xyz ngrok/ngrok:latest start foo bar baz                  # start tunnels from the configuration file
 ```