Skip to main content
Version: 1.21

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.

OptionsValues
--logleveldebug, 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]
OptionsDescription
--disableDisables 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):

OptionsTypeDescriptionDefault
--file(string)The path to the okteto manifest
--no-cache(bool)Do not use cache when building the imagefalse
--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:

  1. Building the image for x86_64 architecture:
okteto build -f Dockerfile -t myapp:latest --platform linux/amd64
  1. Building the image for ARMv7 architecture:
okteto build -f Dockerfile -t myapp:latest --platform linux/arm/v7
  1. 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
OptionsTypeDescription
--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
OptionsTypeDescriptionDefault
--include-token(bool)Include the token in the outputfalse
--output(string)Output format. One of: json, yamljson
{
"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
OptionsTypeDescriptionDefault
--build(bool)Force build of images in the build sectionfalse
--dependencies(bool)Force deployment of repositories in the dependencies sectionfalse
--file(string)The location of the okteto manifest"okteto.yaml"
--name(string)The name of the development environmentThe 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, 3h5m0s
--var(list)Set a pipeline variable (can be set more than once)
--wait(bool)Wait until the pipeline finishesfalse
--no-bash(bool)Execute the command using the container's default shell instead of bashfalse
--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
Options
OptionsTypeDescriptionDefault
--name(string)The name of the development environmentThe 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, 3h5m0s
--volumes(bool)Destroy the persistent volumes created by the development environmentfalse
--wait(bool)Wait until the development environment is destroyedfalse
--no-bash(bool)Execute the command using the container's default shell instead of bashfalse
--all(bool)Destroy everythingfalse
--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.

OptionsTypeDescriptionDefault
--file(string)The path to the okteto manifest"okteto.yaml"
--namespace(string)The namespace to useCurrent Okteto Namespace
--context(string)The context to useCurrent 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
OptionsTypeDescription
--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.

OptionsTypeDescriptionDefault
--file(string)The path to the okteto manifest"okteto.yaml"
--namespace(string)The namespace to useCurrent Okteto Namespace
--context(string)The context to useCurrent 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
OptionsTypeDescriptionDefault
--file(string)The path to the okteto manifest to create"okteto.yaml"
--replace(string)Replace an existing okteto manifestfalse
--namespace(string)The namespace to useCurrent Okteto Namespace
--context(string)The context to useCurrent Okteto Context
-v1(boolean)Use the okteto init v1 versionfalse

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
OptionsTypeDescriptionDefault
--branch(string)The branch to deployThe main branch
--file(string)The location of the okteto manifestIf not set, the automatic deployment rules are applied
--name(string)The name of the pipelineThe folder name
--namespace(string)The Kubernetes namespace to useCurrent 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 namespacefalse
--timeout(duration)The duration to wait for the pipeline to complete. Any value should contain a corresponding time unit e.g. 1s, 2m, 3h5m0s
--var(list)Set a pipeline variable (can be set more than once)
--wait(bool)Wait until the pipeline finishesfalse
--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
OptionsTypeDescriptionDefault
--name(string)The name of the pipelineThe folder name
--namespace(string)The Kubernetes namespace to useCurrent 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, 3h5m0s
--volumes(bool)Destroy the persistent volumes created by the pipelinefalse
--wait(bool)Wait until the pipeline is destroyedfalse

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.

OptionsTypeDescriptionDefault
--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 environmentsCurrent kube config namespace
--context(string)Context where the pipelines to list are deployedCurrent 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.

OptionsTypeDescriptionDefault
--branch(string)The branch to deployYour 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, 3h5m0s
--var(list)Set a preview environment variable (can be set more than once)
--wait(bool)Wait until the preview deployment finishesfalse

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.

OptionsTypeDescriptionDefault
--wait(bool)Wait until the preview deletion finishestrue

endpoints

List the endpoints of a preview environment.

$ okteto preview endpoints [name]

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

OptionsTypeDescription
--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.

OptionsTypeDescription
--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]

More on sleeping resources here.

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.

OptionsTypeDescriptionDefault
--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 3h48h0m0s
--tail(int)The number of lines from the end of the logs to show100
--timestamps(boolean)Print timestamps
--file(string)The path to the manifest file"okteto.yaml"
--namespace(string)The namespace to use to fetch the logsCurrent 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.

OptionsTypeDescriptionDefault
--file(string)The path to the manifest file"okteto.yaml"
--namespace(string)The namespace to useCurrent Okteto Namespace
--context(string)The context to useCurrent 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.

OptionsTypeDescriptionDefault
--file(string)The path to the manifest file"okteto.yaml"
--namespace(string)The namespace to useCurrent Okteto Namespace
--context(string)The context to useCurrent 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.

OptionsTypeDescriptionDefault
--file(string)The path to the manifest file"okteto.yaml"
--namespace(string)The namespace to useCurrent Okteto Namespace
--context(string)The context to useCurrent 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 manifestfalse
--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

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.