---
title: "Configure calicoctl"
description: "Overview reference for configuring calicoctl datastore access in Calico Open Source, comparing config-file, environment-variable, and kubeconfig credential methods."
product: "Calico Open Source"
version: "3.33 (latest)"
section: "Operations"
canonical_url: "https://docs.tigera.io/calico/latest/operations/calicoctl/configure/overview"
---

# Configure calicoctl

## Big picture

Learn how to configure the calicoctl CLI tool for your cluster.

## Value

The `calicoctl` CLI tool provides helpful administrative commands for interacting with a Calico cluster.

## Concepts

### calicoctl vs kubectl

In previous releases, calicoctl has been required to manage Calico API resources in the `projectcalico.org/v3` API group. The calicoctl CLI tool provides important validation and defaulting on these APIs.

In newer releases, the Calico API server performs that defaulting and validation server-side, exposing the same API semantics without a dependency on calicoctl. For this reason, we recommend [installing the Calico API server](https://docs.tigera.io/calico/latest/operations/install-apiserver.md) and using `kubectl` instead of `calicoctl` for most operations.

calicoctl is still required for the following subcommands:

- [calicoctl node](https://docs.tigera.io/calico/latest/reference/calicoctl/node.md)
- [calicoctl ipam](https://docs.tigera.io/calico/latest/reference/calicoctl/ipam.md)
- [calicoctl version](https://docs.tigera.io/calico/latest/reference/calicoctl/version.md)

calicoctl is also required for non-Kubernetes platforms such as OpenStack.

### Default calicoctl behavior

Most `calicoctl` commands require access to the Calico datastore. By default, calicoctl will attempt to read from the Kubernetes API based on the default kubeconfig.

## How to

### Configure access using a Configuration file

By default, `calicoctl` will look for a configuration file at `/etc/calico/calicoctl.cfg`. You can override this using the `--config` option with commands that require datastore access. The file can be in either YAML or JSON format. It must be valid and readable by `calicoctl`. For example:

```yaml
apiVersion: projectcalico.org/v3
kind: CalicoAPIConfig
metadata:
spec:
  datastoreType: 'kubernetes'
  kubeconfig: '/path/to/.kube/config'
```

The `spec` fields are the options in the **Configuration file option** column of the [Kubernetes API datastore](https://docs.tigera.io/calico/latest/operations/calicoctl/configure/kdd.md#complete-list-of-kubernetes-api-connection-configuration) and [etcd datastore](https://docs.tigera.io/calico/latest/operations/calicoctl/configure/etcd.md#complete-list-of-etcd-configuration-options) tables.

### Configure access using environment variables

If `calicoctl` cannot locate, read, or access a configuration file, it will check a specific set of environment variables.

Refer to the section that corresponds to your datastore type for a full set of options and examples.

- [Kubernetes API datastore](https://docs.tigera.io/calico/latest/operations/calicoctl/configure/kdd.md)

- [etcd datastore](https://docs.tigera.io/calico/latest/operations/calicoctl/configure/etcd.md)

> **SECONDARY:** A `calicoctl` container cannot see the host's environment variables or files. Pass environment variables with `-e` and mount configuration files with `-v`. The image has no shell or `sleep` binary, so run a new container for each command. For an example, see [Install calicoctl as a container on a single host](https://docs.tigera.io/calico/latest/operations/calicoctl/install.md#install-calicoctl-as-a-container-on-a-single-host).