Relay CLI provides a variety of ways to configure request routing and also acts as an agent for request forwarding and tunneling. Main features:
- automatically configure bucket, input and output for webhook forwarding with
- automatically configure tunnel with
- manage buckets, inputs and outputs for one-way request forwarding
- manage tunnel subdomains, destinations and authentication details
- manage access keys and secrets
In order to start using your CLI, you first have to authenticate. Create your key & secret pair here: https://my.webhookrelay.com/tokens. Then, there are two ways to do it:
logincommand CLI will take advantage of native secure storage:
- Environment variable option is very useful when automating things:
Forward command automatically creates configuration and starts one-way request forwarding:
- -b –bucket: supply bucket name to reuse existing one. Useful when invoking forward command for the same destination.
- –no-agent: only configure bucket, input and output without starting an agent.
- -t –type: is an output, defaults to internal.
Connect command automatically creates tunnel configuration and starts two-way request streaming:
-r, --region string: is a tunnel region. Select your region based on your location (example: eu, us-west, au)
-d, --destination: is a destination to connect to.
--no-agent: only configures tunnel without starting an agent.
-p --password: is a password for the basic authentication.
-u --username: is a username for the basic authentication.
-t --token: is a token for the token authentication.
-s --subdomain: is an optional parameter for preferred subdomain. If not supplied - random subdomain will be generated.
Buckets are used to group inputs and outputs for webhook relaying. Any request that hits an input in a bucket will be relayed to all outputs inside the same bucket.
To list all buckets:
To update an existing bucket:
To delete existing bucket:
Note that this command will only delete buckets that have no Inputs or Outputs inside, but you can force
delete a bucket:
Inputs are your personal endpoints to receive webhooks.
To list all inputs:
To create an input:
- -b –bucket: is a bucket name to use. Defaults to input name if not supplied.
- -d –description: is a description for the input.
To remove an input
Outputs are destination where requests should be routed
To list all outputs:
To create an output:
-b --bucket: is a bucket name to use. Defaults to output name if not supplied.
-d --destination: is destination where request should be relayed.
-t --type: is output type. Available options: internal (default), public.
--header list: Set request override headers (key=value pairs) (default )
--description: is a description for the output.
To update an output:
-b, --bucket: is a buucket name (required)
-d, --destination: is output destination - where request should be relayed
--header: allows to set request headers (key=value pairs) (default )
--id string: is an output ID
-t, --type string: is output type (available options: internal (default), public) (default ‘internal’) (default “internal”)
To remove an output:
Tokens are used for API, CLI or webhookrelayd authentication.
To list all tokens:
To create a new token:
Once token is generated - secret is already encrypted. Save it somewhere as we don’t store decrypted credentials.
If you lost your token’s secret - just remove it and create a new one.
To remove a token:
Tunnels are used to create bidirectional connections between public endpoint (ie: yourtunnel.webrelay.io) and local endpoint on your computer, private network or even remote website.
To list all tunnels:
To update an existing tunnel:
Usage example to enable public endpoint encryption:
To delete existing tunnel:
Ingresses are tunnels but with additional configuration to enable path based routing, tailored for Kubernetes ingresses. Tunnels that are of type ingress can be created using special group:
Then, these tunnels will be used by the ingress controller.
To view existing ingress type tunnels that already have path based routing rules:
Init command initializes ingress controller in your Kubernetes cluster. It prepares namespace, configures RBAC, provisions credentials for your account and creates a secret:
There are additional options for this command (ie: if you don’t have RBAC enabled in your cluster, use
Reset command removes ingress controller from your cluster. Use this when you don’t want to use ingress controller anymore. However, dormant ingress controller barely uses any resources so it’s recommended to just remove your
ingress.yaml resources to disconnect tunnels.