Skip to main content
Version: 1.25

Remote Execution

The Okteto Manifest allows you to define a list of commands to deploy, test and destroy your application. By default, your commands run locally in your machine, but we recommend that you enable remote execution.

Enable remote execution

Enable remote execution by setting the remote field to true in the deploy/destroy section of your Okteto Manifest:

okteto.yaml
deploy:
remote: true
commands:
- helm upgrade --install movies chart
note

Remote execution is always enabled for okteto test

By default, your commands will run in a remote container using our default container image. The default container image is a Debian Linux container with the following tools preinstalled:

  • bash
  • cue
  • curl
  • envsubst
  • git
  • helm
  • kubectl
  • kustomize
  • make
  • okteto
  • openssh
  • wait-for-it

Remote execution means you don't have to worry about installing tools like helm, kubectl, and others on your local machine.

Defining your own Image

If you need custom tooling or advanced logic, you can use your own image for remote execution. For example, if you want to use the image runner:1.0 as the runtime of your remote execution, configure your Okteto Manifest like this:

okteto.yaml
deploy:
image: runner:1.0
commands:
- helm upgrade --install movies chart

You can use your own image to force specific versions of your deployment tools and ensure that your team has a consistent experience when working with Okteto.

How remote execution works

When running on remote, Okteto will automatically synchronize your local folder to a container running inside Buildkit:

Buildkit architecture

Okteto will connect your local SSH agent with the container running inside Buildkit. For example, this lets you clone any private repository as part of your commands execution as long as your local agent has the proper ssh key configured.

Ignoring files

Okteto looks for a file named .oktetoignore in your local folder. If this file exists, the CLI will exclude any files and directories in the command group that match patterns in it. This helps to avoid unnecessarily synchronizing large or sensitive files and directories that are not used by the commands defined in the deploy, destroy or test section.

An example .oktetoignore file would be the following:

# applied to all commands
docs

# applied to deploy commands only
[deploy]
integration/*

# applied to destroy commands only
[destroy]
app

# applied to all test commands
[test]
app

# applied to unit test command only
[test.unit]
integration

This .oktetoignore expands to the following rules:

  • For deploys, ignores docs and integration/**.
  • For destroys, ignores docs and app.
  • For any test, ignores docs and app.
  • For the unit test specifically, ignores docs, app and integration.

Each command group in .oktetoignore uses the same format as .dockerignore files.

note

For remote deploy and destroy operations, Okteto also reads the legacy .oktetodeployignore file but it will be deprecated in future versions.

Enable remote execution by default

You can also enable remote execution by setting the environment variable OKTETO_FORCE_REMOTE=true. If you define OKTETO_FORCE_REMOTE=true as an Admin Variable, remote execution is enabled for all commands for all developers in your organization. Admin variables are equivalent to defining that variable on every developer's machine.

warning

Local execution is deprecated. Okteto recommends that you enable remote execution for your deploy/destroy commands