Okteto Stacks are for developers who don't want to deal with the complexities of Kubernetes manifests. Okteto Stacks implement and extend the Compose Specification to make it easy to deploy containers in Kubernetes.
The equivalent Kubernetes manifests would have more than 300 lines of yaml!
Define the services that make up your Okteto Stack.
Each service supports the fields in the Compose Specification. We summarize the most relevant ones below:
Indicate how to build the image of this service when running
okteto stack deploy --build. The value is the path to the build context:
It can also be an object with these fields:
context: the build context. When the value supplied is a relative path, it is interpreted as relative to the location of the Okteto Stack manifest file (default:
dockerfile: the path to the Dockerfile. It is a relative path to the build context (default:
target: build the specified stage as defined inside the Dockerfile. See the multi-stage build Docker official docs for details.
args: add build arguments, which are environment variables accessible only during the build process. Build arguments with a value containing a
$sign are resolved to the environment variable value on the machine okteto is running on, which can be helpful for secret or machine-specific values.
okteto stack deploy --build builds a new docker image, pushes it to the registry and redeploys your containers. By default, it builds the images using the Okteto Build Service. Set the variable
BUILDKIT_HOST if you want to use your own BuildKit instance.
Add container capabilities. See
man 7 capabilities for a full list.
Drop container capabilities. See
man 7 capabilities for a full list.
Override the default command of the container image
command can also be a list of strings:
Specify the conditions that the declared services must meet in order for the service to start. The condition must be one of the following:
service_started: Wait until the service is running.
service_healthy: Wait for one of the ports of the dependent service to be available.
service_completed_successfully: Wait until the dependent service has been successfully completed.
You can also express dependencies as a list of services. In this case it will be the same as setting the condition to
Override the default entrypoint of the container image
The entrypoint can also be a list of strings:
Add environment variables from a file to the containers of a service. Environment variables declared in the environment section override these values. This also holds true if those values are empty or undefined.
env_file also accepts a list of files:
Add environment variables:
The container image of each service.
build is defined,
image is optional. Otherwise, it's required.
Specify labels for the service. They translates to Kubernetes annotations.
Ports exposed by each service. By default, they're only accessible from the cluster private network.
To make the port public, use the following notation:
In you need need to configure HTTPS routes, use endpoints instead of configuring an NGINX container in your Docker Compose file.
The following ports are never made public:
In you need make these ports public, you can use endpoints.
Specify the number of containers running for each service (default:
Configure resource requests and limits.
reservations translates to Kubernetes
Defines the policy that the platform will apply on container termination.
always/unless-stopped/any: The default restart policy. The policy always restarts the container until its removal.
none/never/no: The policy does not restart a container under any circumstances.
on-failure: The policy restarts a container if the exit code indicates an error.
If the restart policy is other than always, the service will be translated to a Kubernetes Job.
Specify how long to wait when attempting to stop a container before sending SIGKILL. If no unit of time is given, the system will interpret the number in seconds.
Define volumes accessible by the containers of a service at a given path.
redis must be defined in the volumes section.
The following notation is also accepted:
Override the default working directory of the container image
List of volumes created by the Okteto Stack. Volumes are mounted on the containers of a given service by referring the volume from the volumes field of the service.
Each volume has the following properties:
Specify labels for the volume. They translates to Kubernetes annotations.
Specify the storage class of the volume.
Specify the size of the volume. Defaults to 1Gi.
There are multiple parts of Okteto Stacks that deal with environment variables in one sense or another. This section should help you find the information you need.
It’s possible to use environment variables in your shell to populate values inside your Okteto Stack:
If you have multiple environment variables, you can substitute them by adding them to a file named
You can set default values for any environment variables referenced in your Okteto Stack in an environment file named
.env file is placed at the same folder than the Okteto Stack manifest.
When you run
okteto stack deploy the
web container uses the image
Values in the shell take precedence over those specified in the
You can also use your Okteto Secrets in your Okteto Stack.
For example, if your have an Okteto Secret named
PASSWORD whose value is
change-me!, the following Okteto Stack:
change-me! for the value of the
MYSQL_ROOT_PASSWORD environment variable of the
mysql service when you run
okteto stack deploy.
Values in the shell and/or the
.envfile take precedence over those specified in Okteto Secrets.
Okteto Stacks extends the Compose Specification to make it even easier for you and your team to build cloud-native applications.
The name of the Okteto Stack. Used by the Okteto UI to group the resources created by this stack. Defaults to the name of the git repository. If the current path doesn't belong to a git repository, defaults to the name of the current folder.
The namespace where you want to deploy your Okteto Stack. If not specified, it uses the current Okteto namespace.
Endpoints expose HTTPS routes from outside the cluster to services within the cluster. Use this instead of having to run a NGINX proxy in your Docker Compose file.
The endpoint uses the name of the stack to generate a URL with the following format: https://STACK_NAME-NAMESPACE.cloud.okteto.net.
Each endpoint has the following properties:
The request path that will handle this route.
The service that will receive the request.
The port that will receive the request.
If more than one endpoint is needed, you can declare multiple endpoints by using a map with the name of the endpoint and its specification:
endpoints also accepts an extended notation to specify labels for each endpoint: