Skip to main content

gws apply

Apply Kubernetes manifests to the current deployment's namespace using GetWebstack's embedded Kubernetes client. No kubectl dependency.

Mostly used internally by the watch orchestrator (when a .gws/services/<svc>/k8s/*.yaml changes on disk it gets re-applied), but exposed as a top-level command for advanced use cases — for example, applying a one-off Job or ConfigMap against the active deployment without re-running gws up.

Most users should not need this directly. If you're trying to refresh a service's image, use gws rebuild. If you're trying to re-deploy everything, use gws up.

Usage​

gws apply <manifest> [options]
ArgumentDescription
manifestPath to a single YAML file or a directory containing YAML files.
FlagDescription
-w, --worktree <name>Worktree to target (defaults to active worktree).

Auth: requires an active deployment for the target project / worktree — gws up must have been run for it. gws apply does not bring a deployment up; if you point -w at a worktree that isn't currently deployed, the command will fail with No active deployment found.

Behaviour​

  • Resolves the project + worktree the same way every other BaseCommand does (current directory or -w).
  • Looks up the deployment in local state to get the cluster's kubeconfigPath and kubeContext.
  • The namespace is always the deployment's deploymentId — manifests' metadata.namespace is overwritten via forceNamespace: true so you can't accidentally apply into the wrong namespace.
  • A directory argument applies every YAML file in it; a single file argument applies just that file.

If no deployment is found for the current path, the command exits with No active deployment found for current directory. Run 'gws up' first.

Examples​

# Apply a one-off ConfigMap
gws apply ./extra-config.yaml

# Apply a directory of manifests
gws apply ./.gws/extra-manifests/

# Target a different worktree
gws apply ./extra-config.yaml -w feature-payments

See also​