Version: 1.22

Okteto CLI

The Okteto Command Line Interface is a unified tool to manage your development environments.

Synopsis

$ okteto [options] <command> <subcommand> [parameters]

Use okteto command --help for information on a specific command. The synopsis for each command shows its parameters and their usage. Optional parameters are shown in square brackets.

Options	Values
--loglevel	debug, info, warn, error

The amount of information outputted (defaults to warn).

Advanced configuration

It is possible to handle timeouts from the client side when communicating with the buildkit daemon through the Okteto CLI. To do so, the following environment variables can be modified:

OKTETO_KEEPALIVE_CLIENT_TIME_MS: After this duration of time, if the client doesn't see any activity it will ping the server to see if the transport is still alive. If set below 10s, a minimum value of 10s will be used (default value is infinity.)
OKTETO_KEEPALIVE_CLIENT_TIMEOUT_MS: After sending a keepalive ping, the client waits for this duration of time and if no activity is seen even after that the connection is closed. (default value is 20 seconds.)
OKTETO_KEEPALIVE_CLIENT_PERMIT_WITHOUT_STREAM: If true, the client sends keepalive pings even with no active RPCs. If false, when there are no active RPCs, Time and Timeout will be ignored and no keepalive pings will be sent (defaults to false.)

Available commands

analytics

Enable / Disable analytics collection. Analytics are enabled by default

$ okteto analytics [parameters]

Options	Description
--disable	Disables analytic collection

Okteto only collects information to help us understand how our users interact with the product. We don't collect any personally identifiable information.

When you use the okteto CLI, the following information is collected:

The name of the action
A timestamp of when it was run
Your version of the CLI
Your OS
An anonymous machine ID (we use https://github.com/denisbrodbeck/machineid for this)
A user ID if you are currently logged in to Okteto
An action ID (to correlate multiple actions performed during a command's execution)

Please reach out to us if you have any questions or concerns about the information collected.

build

Build and push the images defined in the build section of your Okteto Manifest:

$ okteto build [service...]

If your okteto context points to an Okteto URL, images are built using the Okteto Build Service. Otherwise, images are built using your local Docker daemon. If you want to use another BuildKit instance, set the variable BUILDKIT_HOST to point to its address, using the format HOST:PORT.

The following flags can be used (very similar to docker build):

Options	Type	Description	Default
--file	(string)	The path to the okteto manifest
--no-cache	(bool)	Do not use cache when building the image	`false`
--secret	(list)	Secret files exposed to the build. Format: `id=mysecret,src=/local/secret`
--export-cache	(string)	Image tag for exported cache when build (optional)
--cache-from	(list)	List of cache source images (optional)
--platform	(string)	Specify which platform to build the container image for (optional)

You can also use the -f to point to a Dockerfile. In this mode, okteto build will ignore your Okteto manifest, and directly build the image defined in the Dockerfile. Use this to build images that are not defined on your Okteto manifest.

With okteto build --platform you can specify the platform (or architecture) for which you'd like to build the container images. For example, you could use a multiplatform image and the okteto build --platform command to deploy your web application on a Kubernetes cluster that consists of nodes running on both x86-64 and ARMv7 architectures. By using the multiplatform images built using this method, you can deploy the same images across the cluster without worrying about the underlying hardware differences.

Let's consider an example where you have a Node.js application that you want to build and deploy on both x86_64 and ARM-based platforms. You have a Dockerfile in your project directory that defines the build process. Here's how Okteto CLI can help you build multiplatform images for your application:

Building the image for x86_64 architecture:

okteto build -f Dockerfile -t myapp:latest --platform linux/amd64

Building the image for ARMv7 architecture:

okteto build -f Dockerfile -t myapp:latest --platform linux/arm/v7

Building a multiarchitectural image:

okteto build -f Dockerfile -t myapp:latest --platform linux/amd64,linux/arm/v7

This command builds a multi-architecture Docker image named myapp with the latest tag for both x86_64 and ARM platforms.

By using these commands, you can easily build the application image for different platforms without needing to maintain separate Dockerfiles or perform manual modifications. This is particularly useful when you want to deploy your application to heterogeneous environments where you have both x86_64 and ARM-based devices, such as a mixed-cluster Kubernetes setup.

context

Set the default context.

A context is a group of cluster access parameters. Each context contains a Kubernetes cluster, a user, and a namespace. The current context is the default cluster/namespace for any Okteto CLI command.

$ okteto context

This will prompt you to select one of your existing contexts or to create a new one:

A context defines the default cluster/namespace for any Okteto CLI command.
Select the context you want to use:
Use the arrow keys to navigate: ↓ ↑ → ←
  ▸ https://okteto.example.com *
    minikube

    Create new context

Options	Type	Description
--token	(string)	API token for authentication. Use this when scripting or if you don't want to use browser-based authentication.
--namespace	(string)	Namespace of your okteto context
--builder	(string)	URL of the builder service

When you run okteto context, an account will be created for your own URL if it's the first time you set the context in. The CLI will exchange an authorization token with URL and save your API token and Okteto certificates information under $HOME/.okteto/.

tip

In your CI/CD you should use environment variables to specify your Okteto Context, Namespace and token. Check out Environment Variables to know more.

Available subcommands:

delete

Delete one or more contexts.

For example, to delete the Okteto context, run:

$ okteto context delete https://okteto.example.com https://okteto2.example.com

list

List available contexts.

$ okteto context list

Name                               Namespace    Builder                                   Registry
https://okteto.example.com *       cindy        tcp://buildkit.okteto.example.com:1234    registry.okteto.example.com
minikube                           default      docker                                    -

show

Print the current context.

$ okteto context show

Options	Type	Description	Default
--include-token	(bool)	Include the token in the output	`false`
--output	(string)	Output format. One of: `json`, `yaml`	`json`

{
  "name": "https://okteto.example.com",
  "token": "REDACTED", # only printed using flag: --include-token
  "namespace": "cindy",
  "builder": "tcp://buildkit.okteto.example.com:1234",
  "registry": "registry.okteto.example.com",
  "isOkteto": true
}

use

Set the default context.

$ okteto context use

This will prompt you to select one of your existing contexts or to create a new one.

You can also specify an Okteto URL:

$ okteto context use https://okteto.example.com

 ✓  Using context cindy @ okteto.example.com

Or a Kubernetes context:

$ okteto context use minikube

 ✓  Using context default @ minikube

deploy

Deploy your development environment by running the commands specified in the deploy section of your okteto manifest. If the images in the build section don't exist, okteto deploy automatically builds and pushes all these images. If the repositories in the dependencies section haven't been deployed yet, okteto deploy deploys these dependencies automatically.

The command is executed relative to the path where the manifest is located. This means, that if the manifest is at any subfolder, the pipeline will use the context of the subfolder where the manifest is defined.

$ okteto deploy

Options

Options	Type	Description	Default
--build	(bool)	Force build of images in the `build` section	`false`
--dependencies	(bool)	Force deployment of repositories in the `dependencies` section	`false`
--file	(string)	The path to the okteto manifest	"okteto.yaml"
--help	(bool)	Help for the deploy command	`false`
--name	(string)	The name of the development environment	The repo/folder name
--namespace	(string)	Overwrites the namespace where the development environment is deployed
--timeout	(duration)	The duration to wait for the development environment deployment to complete. Any value should contain a corresponding time unit e.g. 1s, 2m, 3h	5m0s
--var	(list)	Set a pipeline variable (can be set more than once)
--wait	(bool)	Wait until the pipeline finishes	`false`
--no-bash	(bool)	Execute the command using the container's default shell instead of bash	`false`
--remote	(bool)	Run the deploy commands in your Okteto cluster. Okteto will connect your local SSH agent with the cluster. For example, this lets you clone any private repository as part of your manifest execution as long as your local agent has the proper ssh key configured

Executed commands will be executed using bash unless the --no-bash flag has been specified.

destroy

Destroy your development environment. It automatically destroys all the Kubernetes resources created by okteto deploy. If you need to destroy external resources (like s3 buckets or other Cloud resources), use the destroy section of the Okteto Manifest.

$ okteto destroy

The okteto destroy command will only destroy resources matching the specified Development Environment name. By default, this is the name of the folder, but you can specify the name in the Okteto Manifest, or with the --name flag. In a monorepo scenario, where you might have several manifests, you need to specify the correct manifest to destroy the specific development environment. This ensures that the appropriate destroy commands, as defined in your Okteto manifest, are executed within a particular scope.

This way, executing the okteto destroy command on one Development Environment will not delete the other. For example, if you have two Development Environments, dev1 and dev2, and you run okteto destroy for dev1, it will only destroy the resources for dev1 and leave dev2 intact.

You can use okteto destroy --all to delete all Development Environments.

Options

Options	Type	Description	Default
--all	(bool)	Destroy all development environments, excluding resources annotated with `dev.okteto.com/policy: keep`	`false`
--context	(string)	Context where the development environment was deployed	Your existing context
--dependencies	(bool)	Force destroy repositories in the `dependencies` section	`false`
--file	(string)	The path to the okteto manifest	"okteto.yaml"
--force-destroy	(bool)	Forces the development environment to be destroyed even if there is an error executing the custom destroy commands defined in the manifest	`false`
--help	(bool)	Help for the destroy command	`false`
--name	(string)	The name of the development environment	The folder name
--namespace	(string)	Overwrites the namespace where the development environment is deployed
--timeout	(string)	The duration to wait for the development environment to be destroyed. Any value should contain a corresponding time unit e.g. 1s, 2m, 3h	5m0s
--volumes	(bool)	Destroy the persistent volumes created by the development environment	`false`
--wait	(bool)	Wait until the development environment is destroyed	`false`
--no-bash	(bool)	Execute the command using the container's default shell instead of bash	`false`
--remote	(bool)	Run the deploy commands in your Okteto cluster. Okteto will connect your local SSH agent with the cluster. For example, this lets you clone any private repository as part of your manifest execution as long as your local agent has the proper ssh key configured

Executed commands will be executed using bash unless the --no-bash flag has been specified.

Resources annotated with dev.okteto.com/policy: keep will not be affected by the destroy action.

doctor

Generates a doctor file with the okteto logs for a given development container:

$ okteto doctor [devName]

The doctor command should be run from the folder where you ran okteto up.

The doctor file contains:

The okteto.log
The syncthing logs of your development container
A summary of your development container manifest
A metadata file with information about your host machine's OS and architecture

The doctor file is a handy way to collect all the okteto logs. Use it when filing an issue or asking the Okteto community for help.

down

Deactivates your development container, stops the file synchronization service, and restores your previous deployment configuration for a given development container.

$ okteto down [devName]

The down command should be run from the same location as okteto up.

Options	Type	Description	Default
--file	(string)	The path to the okteto manifest	"okteto.yaml"
--namespace	(string)	The namespace to use	Current Okteto Namespace
--context	(string)	The context to use	Current Okteto Context
--volumes	(bool)	Remove persistent volumes where your local folder is synched on remote

endpoints

List the public endpoints of your development environment.

$ okteto endpoints

Options	Type	Description
--output	(string)	Output format. One of: ['json', 'md']

exec

Executes the COMMAND in your development container. The command will fail if there's no active development container corresponding to the current folder.

$ okteto exec [devName] -- COMMAND

The exec command should be run from the same location as okteto up.

Options	Type	Description	Default
--file	(string)	The path to the okteto manifest	"okteto.yaml"
--namespace	(string)	The namespace to use	Current Okteto Namespace
--context	(string)	The context to use	Current Okteto Context

help

Displays the full help

$ okteto help

init

This command walks you through creating your Okteto Manifest. It only covers the most common items, and tries to guess sensible defaults. See the Okteto Manifest documentation for more details about the Okteto Manifest.

$ okteto init

Options	Type	Description	Default
--file	(string)	The path to the okteto manifest to create	"okteto.yaml"
--replace	(string)	Replace an existing okteto manifest	`false`
--namespace	(string)	The namespace to use	Current Okteto Namespace
--context	(string)	The context to use	Current Okteto Context
-v1	(boolean)	Use the okteto init v1 version	`false`

kubeconfig

Download credentials for the Kubernetes cluster selected via okteto context.

$ okteto kubeconfig

 i  Updated kubernetes context 'okteto_example_com/cindy' in '/Users/cindy/.kube/config'

Starting with the Okteto CLI 2.20, the Kubeconfig file generated by Okteto uses a credential plugin to get the Kubernetes credentials from your Okteto instance. This functionality requires the okteto CLI to be in your PATH. It is also required that the Okteto CLI is connected to your Okteto instance through okteto context use <url>

Prior to the implementation of the credential plugins, kubeconfigs were generated using secret-based service account tokens that have no expiration. You can enable the previous behavior of static tokens by setting the environment variable OKTETO_USE_STATIC_KUBETOKEN to true before running okteto kubeconfig. Be aware that using those static tokens are not recommended by Kubernetes and you will receive warnings in your kubectl output starting with kubernetes version 1.27.

namespace

Configure the current namespace of the okteto context.

$ okteto namespace

This will prompt you to select one of your existing namespaces:

Select the namespace you want to use:
Use the arrow keys to navigate: ↓ ↑ → ←
  ▸ cindy

    Create new namespace

 ✓  Using context cindy @ okteto.example.com

create

Create a namespace. By default the command will switch to the new namespace, add --use=false to create the namespace, and it will keep the current namespace active.

This command is only available in clusters that have Okteto installed.

$ okteto namespace create test-cindy

 ✓  Namespace 'test-cindy' created
 ✓  Using context test-cindy @ okteto.example.com

delete

Delete a namespace. If the manifest includes destroy commands, they will be executed as part of this command. By default, it deletes the current okteto namespace.

This command is only available in clusters that have Okteto installed.

$ okteto namespace delete test-cindy

 ✓  Namespace 'test-cindy' deleted

list

List existing namespace.

This command is only available in clusters that have Okteto installed.

$ okteto namespace list

Namespace       Status
demos-cindy     Active
cindy *         Active

use

Set the default okteto namespace.

$ okteto namespace use cindy

 ✓  Using context cindy @ okteto.example.com

sleep

Sleeps an okteto namespace. By default, it sleeps the current okteto namespace.

$ okteto namespace sleep [name]

i  Using test-cindy @ okteto.example.com as context
✓  Namespace 'test-cindy' is sleeping

If you'd like to sleep a namespace other than the current one, you can provide that namespace name as an argument to the command.

wake

Wakes an okteto namespace. By default, it wakes the current okteto namespace.

$ okteto namespace wake [name]

i  Using test-cindy @ okteto.example.com as context
✓  Namespace 'test-cindy' is awake now

If you'd like to wake a namespace other than the current one, you can provide that namespace name as an argument to the command.

pipeline

Pipeline management commands

$  okteto pipeline [command]

Available subcommands:

deploy

Runs a job in the cluster that clones your repository and executes okteto deploy on it. This is equivalent to clicking the Deploy Dev Environment button on the Okteto UI and selecting a git repository.

$ okteto pipeline deploy

You must be logged in to Okteto before running this command.

Options

Options	Type	Description	Default
--branch	(string)	The branch to deploy	The main branch
--file	(string)	The location of the okteto manifest	If not set, the automatic deployment rules are applied
--name	(string)	The name of the pipeline	The folder name
--namespace	(string)	The Kubernetes namespace to use	Current kube config namespace
--repository	(string)	The HTTPS url of the repository to deploy (e.g. https://github.com/okteto/movies)
--skip-if-exists	(bool)	Skip the pipeline deployment if the pipeline already exists in the namespace	`false`
--timeout	(duration)	The duration to wait for the pipeline to complete. Any value should contain a corresponding time unit e.g. 1s, 2m, 3h	5m0s
--var	(list)	Set a pipeline variable (can be set more than once)
--wait	(bool)	Wait until the pipeline finishes	`false`
--label	(list)	Tag and organize development environments using labels (multiple --label flags accepted)
--reuse-params	(bool)	If pipeline exist, reuse same parameters to redeploy)

destroy

Runs a job in the cluster that clones your repository and executes okteto destroy on it. This is equivalent to clicking the Destroy button on the Okteto UI.

$ okteto pipeline destroy

You must be logged in to Okteto before running this command.

Options

Options	Type	Description	Default
--name	(string)	The name of the pipeline	The folder name
--namespace	(string)	The Kubernetes namespace to use	Current kube config namespace
--timeout	(string)	The duration to wait for the pipeline to be destroyed. Any value should contain a corresponding time unit e.g. 1s, 2m, 3h	5m0s
--volumes	(bool)	Destroy the persistent volumes created by the pipeline	`false`
--wait	(bool)	Wait until the pipeline is destroyed	`false`

list

List all your Okteto development environments in the current namespace.

$ okteto pipeline list

Run okteto pipeline list to get the status and info of your development environments.

You must be logged in to Okteto before running this command.

Options	Type	Description	Default
--label	(list)	Tag and organize development environments using labels (multiple --label flags accepted)
--output	(string)	Output format. One of: ['json', 'yaml']
--namespace	(string)	The Kubernetes namespace to use to list the development environments	Current kube config namespace
--context	(string)	Context where the pipelines to list are deployed	Current Okteto context

preview

Preview environment management commands.

This command is only available in clusters that have Okteto installed.

$  okteto preview [command]

deploy

Deploy an okteto preview environment.

$ okteto preview deploy [name]

Run okteto preview deploy to automatically deploy a preview environment for your branch.

You must be logged in to Okteto before running this command. Only users with admin access can deploy a global preview environment.

Options	Type	Description	Default
--branch	(string)	The branch to deploy	Your current branch
--file	(string)	The location of the okteto manifest. If not set, the automatic deployment rules will be applied.
--label	(list)	Tag and organize preview environments using labels (multiple --label flags accepted)
--repository	(string)	The url of the repository to deploy (e.g. https://github.com/okteto/movies)	Your current git configuration repo
--scope	(string)	The scope of preview environment to create. Accepted values are ['personal', 'global']. A personal preview environment can only be accessed by its creator, while in a global preview environment all cluster users can access it.	`personal`
--sourceUrl	(string)	The HTTPS url of the pull/merge request to deploy.
--timeout	(duration)	The duration to wait for the preview deployment to complete. Any value should contain a corresponding time unit e.g. 1s, 2m, 3h	5m0s
--var	(list)	Set a preview environment variable (can be set more than once)
--wait	(bool)	Wait until the preview deployment finishes	`false`

destroy

Destroy your okteto preview environment.

$ okteto preview destroy [name]

Run okteto preview destroy to destroy a given preview environment.

You must be logged in to Okteto before running this command. Only users with administration privileges can destroy a global preview environment. If the manifest includes destroy commands, they will be executed as part of this command.

Options	Type	Description	Default
--wait	(bool)	Wait until the preview deletion finishes	`true`

endpoints

List the endpoints of a preview environment.

$ okteto preview endpoints [name]

You must be logged in to Okteto before running this command.

Options	Type	Description
--output	(string)	Output format. One of: ['json']

Output flag can be used to parse the endpoints and add them to your PR with a custom layout.

list

List all your okteto preview environments.

$ okteto preview list

Run okteto preview list to get the status and scope of your preview environments.

You must be logged in to Okteto before running this command.

Options	Type	Description
--label	(list)	tag and organize preview environments using labels (multiple --label flags accepted)
--output	(string)	Output format. One of: ['json', 'yaml']

sleep

Sleeps a given Okteto preview environment. Only users with admin access or who own the preview environment can take this action.

$ okteto preview sleep [name]

wake

Wakes an Okteto preview environment. You must provide the name of a preview environment as an argument for this command.

$ okteto namespace wake [name]

logs

Fetch the logs of your development environment.

$ okteto logs [serviceName]

The okteto logs command should be run from the same location than okteto up.

The first argument is optional and it's a regex matching the name of the services you want to fetch the logs from. For example, okteto logs api fetches the logs of any service starting with api.

Options	Type	Description	Default
--all	(boolean)	Fetch logs from the whole namespace
--exclude	(string)	Exclude by service name (regular expression)
--since	(duration)	Return logs newer than a relative duration like 5s, 2m, or 3h	48h0m0s
--tail	(int)	The number of lines from the end of the logs to show	100
--timestamps	(boolean)	Print timestamps
--file	(string)	The path to the manifest file	"okteto.yaml"
--namespace	(string)	The namespace to use to fetch the logs	Current Okteto namespace
--context	(string)	The context to use to fetch the logs

restart

Restarts your development pods corresponding to the services section of the okteto manifest for a given development container. This is useful to reload configurations that cannot be hot-reloaded.

$ okteto restart [devName]

The restart command should be run from the same location than okteto up.

Options	Type	Description	Default
--file	(string)	The path to the manifest file	"okteto.yaml"
--namespace	(string)	The namespace to use	Current Okteto Namespace
--context	(string)	The context to use	Current Okteto Context

status

Status of the file synchronization process for a given development container:

$ okteto status [devName] --info

 i  Local syncthing url: http://localhost:60539
 i  Remote syncthing url: http://localhost:60538
 i  Syncthing username: okteto
 i  Syncthing password: ac0ee34a-b1aa-4a41-bc67-cec3128b6cfd
 ✓  Synchronization status: 100.00%

The status command should be run from the same location than okteto up.

Options	Type	Description	Default
--file	(string)	The path to the manifest file	"okteto.yaml"
--namespace	(string)	The namespace to use	Current Okteto Namespace
--context	(string)	The context to use	Current Okteto Context
--info	(bool)	Show syncthing links for troubleshooting the synchronization service
--watch	(bool)	Watch for changes

up

Activate a development container. If needed, okteto up builds the images and runs the deploy commands defined in your Okteto Manifest.

$ okteto up [devName]

When you run okteto up, okteto scales to zero the specified deployment and creates a mirror deployment. The mirror deployment is a copy of the original deployment manifest with the following development-time improvements:

Okteto overrides the container-level configuration of the original deployment with the values defined in your okteto manifest. A typical example of this is to replace the production container image with one that contains your development runtime.
A bidirectional file synchronization service is started to keep your changes up to date between your local filesystem and your development container.
Automatic local and remote port forwarding using SSH. This allows you to do things like access your cluster services via localhost or connect a remote debugger.
A watcher service to keep the definition of the mirror deployment up to date with original deployment.

It's worth noting that your development deployment inherits the original deployment manifest definition. Therefore, the development deployment uses the same service account, environment variables, secrets, volumes, sidecars, ... than the original deployment, providing a fully integrated development environment.

Run okteto down to restore your original deployment.

Options	Type	Description	Default
--file	(string)	The path to the manifest file	"okteto.yaml"
--namespace	(string)	The namespace to use	Current Okteto Namespace
--context	(string)	The context to use	Current Okteto Context
--env	(list)	Set environment variable in the dev container
--deploy	(bool)	Force execution of the commands in the `deploy` section of the okteto manifest	`false`
--reset	(bool)	Resets the file synchronization service. Use it if the file synchronization service stops working.
--command	(list)	The command to execute in the dev container. This overrides the command specified in the `dev` section of the manifest. For example: `okteto up --command npm --command start`

version

Displays the current installed version

$ okteto version

test

Runs tests using Okteto infrastructure via Remote Execution. Since tests run inside the cluster, all internal endpoints are available inside the test exection. For example, if you deployed an api service on port 8080 it will be accesible at: http://api.${OKTETO_NAMESPACE}:8080.

Dynamic endpoints are available within test section.

Options	Type	Description	Default
--file	(string)	The path to the manifest file	"okteto.yaml"
--namespace	(string)	The namespace to use	Current Okteto Namespace
--name	(string)	The name of the development environment name to be deployed
--context	(string)	The context to use	Current Okteto Context
--deploy	(bool)	Force execution of the commands in the `deploy` section of the okteto manifest	`false`
--no-cache	(bool)	By default, test container `caches` are reused between executions	`false`
--var	(list)	Set a pipeline variable (can be set more than once)
--timeout	(duration)	The duration to wait for the development environment deployment to complete. Any value should contain a corresponding time unit e.g. 1s, 2m, 3h	5m0s

Troubleshooting

Kubernetes authentication

After you've ran okteto kubeconfig you should be able to communicate with the cluster through tools like kubectl and helm. If you are getting errors when trying to do so, you can use the okteto kubetoken command to troubleshoot the issue. This command is used internally as your authentication plugin against the cluster.

When running

$ okteto kubetoken <okteto_url> <namespace> # example: okteto kubetoken https://okteto.example.com cindy

You should see a message like this:

{
  "apiVersion": "client.authentication.k8s.io/v1",
  "metadata": {
    "creationTimestamp": null,
    "managedFields": [
      {
        "manager": "backend",
        "operation": "Update",
        "apiVersion": "authentication.k8s.io/v1",
        "time": "2023-03-01T13:18:48Z",
        "fieldsType": "FieldsV1",
        "fieldsV1": {
          "f:spec": {
            "f:expirationSeconds": {}
          }
        },
        "subresource": "token"
      }
    ]
  },
  "spec": {
    "audiences": ["<your-cluster-audience>"],
    "expirationSeconds": 1800,
    "boundObjectRef": null
  },
  "status": {
    "token": "<your.jwt.token>",
    "expirationTimestamp": "2023-03-01T13:48:48Z"
  }
}

If you are getting something else, you should be receiving an error message with guidance on how to follow up.

Synopsis​

Advanced configuration​

Available commands​

analytics​

build​

context​

delete​

list​

show​

use​

deploy​

Options​

destroy​

Options​

doctor​

down​

endpoints​

exec​

help​

init​

kubeconfig​

namespace​

create​

delete​

list​

use​

sleep​

wake​

pipeline​

deploy​

Options​

destroy​

Options​

list​

preview​

deploy​

destroy​

endpoints​

list​

sleep​

wake​

logs​

restart​

status​

up​

version​

test​

Troubleshooting​

Kubernetes authentication​

Synopsis

Advanced configuration

Available commands

analytics

build

context

delete

list

show

use

deploy

Options

destroy

Options

doctor

down

endpoints

exec

help

init

kubeconfig

namespace

create

delete

list

use

sleep

wake

pipeline

deploy

Options

destroy

Options

list

preview

deploy

destroy

endpoints

list

sleep

wake

logs

restart

status

up

version

test

Troubleshooting

Kubernetes authentication