Skip to main content
Version: 1.24

Advanced Commands & Concepts for Developers

Advanced CLI Commands

CommandDescription
okteto namespaceAllows you to manage namespaces by using commands like create, delete, use, and more
okteto execAllows you to execute a command in your development container. okteto exec [devName] -- COMMAND
okteto destroyDestroys a currently deployed Development Environment. Note that this does not destroy persistent volumes that were created for that Development Environment, to do so, pass the -v flag
okteto logsUsed to view the logs of a Development Environment
okteto endpointsUsed to view your application’s HTTPS URLs automatically generated by Okteto
okteto doctorGenerates a doctor file with the okteto logs for a given Development Container. This file can be useful when asking Okteto support for help
okteto statusShows the status of the file synchronization process for a given Development Container

A list of all available CLI commands is in our full CLI reference guide here ->

Commonly Used CLI Flags

  • okteto deploy --dependencies: Re-deploys dependencies defined in your okteto manifest
  • okteto deploy --build: Forces a rebuild of the images, incorporating any local changes
  • okteto build --no-cache: Do not use a cache when building an image
  • okteto destroy --volumes: Destroy the persistent volumes created by the development environment. Persistent volumes are a storage resource that persists beyond the lifecycle of the Development Environment. This allows data to survive and be accessible by new Development Applications that may be created later. This could be useful for data for databases or application state while developing.
  • okteto destroy --all: Destroy all Development Environments, including resources annotated with dev.okteto.com/policy: keep

Concepts to Understand

Namespaces

Namespaces in Okteto are where Development Environments get deployed. Each developer starts with a personal Namespace which has the same name as their account but can create as many different Namespaces as they need.

A Namespace can be used for varying durations depending on your needs—ranging from a few weeks for developing a feature to just a couple of days for fixing a bug. Namespaces provide a dedicated environment for isolated development, and they can also be shared among team members to collaborate on work before pushing changes to Git.

However, many developers prefer to use a single namespace as a replacement for their local environment. In this workflow, instead of creating a new namespace for each feature or bug fix, they switch branches within the same namespace to work on different tasks. This approach mirrors the traditional local development process and eliminates the need to reinitialize data for each new namespace.

When switching branches, it's important to ensure your environment is up-to-date. If your changes involve only code, running okteto up is sufficient to sync your changes. However, if the branches include changes to manifest files, you'll need to run okteto deploy to fully apply the updates.

This flexibility allows you to choose the workflow that best fits your development process, whether it's using separate namespaces for isolation or a single namespace for continuity and efficiency.

Read the full Namespace documentation here ->

Development Environments

Development Environments enable developers to create applications in the cloud without having to worry about Kubernetes. Everything is pre-configured in the Okteto Manifest. This way developers spend less time troubleshooting their Development Environment and more time coding cool features.

Read the full Development Environment documentation here ->

Development Containers

Okteto makes it easier to develop on Kubernetes by using Development Containers. They allow you to hot reload and debug your Development Environments as fast as you write code 🚀

Development Containers can be run in two different modes:

  • File Sync Development Mode: Syncs your local changes to your remote development container (default mode).
  • Hybrid Development Mode: Runs your service locally and simulates your laptop belonging to the cluster network by using SSH tunnels. This may be helpful if you work with large file sizes in part of your application. Okteto Code Sync does not run while using hybrid mode since the changes are built locally.

Read the full Development Container documentation here ->

Development Images

Development images define the runtime your application runs in during development, ensuring consistency and reproducibility across different stages of your workflow, developers, and different local machines.

Read the full Development Image documentation here ->

Variables

Environment variables are useful for storing user-specific configuration values that are not shared with the rest of the team. They can also be useful when you need to specify ad-hoc variables at the time of deployment.

Read the full Okteto Variables documentation here ->

Okteto Preview Environments

Okteto's Preview Environments automatically generate a unique, shareable version of your application for each pull request, making code reviews, automated end-to-end testing, and stakeholder feedback a breeze. Your platform team will need to set up Preview Environments if they are not already configured.

Read the full Preview Environment documentation here ->

FAQ

When does okteto deploy look at the Git repo vs my own code?

  • okteto deploy uses the code from your Git repository to deploy the application. After running okteto up, Okteto’s file sync will update your changes remotely

What’s the difference between okteto up and okteto up --deploy?

  • okteto up creates the Development Environment of a service based on its previously deployed version.
  • okteto up --deploy runs the okteto deploy section first, picking up any new changes from the repository, and then connects to the Development Environment.

What does okteto deploy --build do?

  • This command forces a rebuild of the images, incorporating any local changes. It rebuilds all images, not just the ones with changes. This will be the default behavior in CLI version 3.0

Additional Support and Help Getting Started