# Feast CLI reference

## Overview

The Feast CLI comes bundled with the Feast Python package. It is immediately available after [installing Feast](../how-to-guides/feast-gcp-aws/install-feast).

```
Usage: feast [OPTIONS] COMMAND [ARGS]...

  Feast CLI

  For more information, see our public docs at https://docs.feast.dev/

  For any questions, you can reach us at https://slack.feast.dev/

Options:
  -c, --chdir TEXT  Switch to a different feature repository directory before
                    executing the given subcommand.

  --help            Show this message and exit.

Commands:
  apply                    Create or update a feature store deployment
  entities                 Access entities
  feature-views            Access feature views
  init                     Create a new Feast repository
  materialize              Run a (non-incremental) materialization job to...
  materialize-incremental  Run an incremental materialization job to ingest...
  registry-dump            Print contents of the metadata registry
  teardown                 Tear down deployed feature store infrastructure
  version                  Display Feast SDK version
```

## Global Options

The Feast CLI provides one global top-level option that can be used with other commands

**chdir (-c, --chdir)**

This command allows users to run Feast CLI commands in a different folder from the current working directory.

```
feast -c path/to/my/feature/repo apply
```

## Apply

Creates or updates a feature store deployment

```bash
feast apply
```

**What does Feast apply do?**

1. Feast will scan Python files in your feature repository and find all Feast object definitions, such as feature views, entities, and data sources.
2. Feast will validate your feature definitions
3. Feast will sync the metadata about Feast objects to the registry. If a registry does not exist, then it will be instantiated. The standard registry is a simple protobuf binary file that is stored on disk (locally or in an object store).
4. Feast CLI will create all necessary feature store infrastructure. The exact infrastructure that is deployed or configured depends on the `provider` configuration that you have set in `feature_store.yaml`. For example, setting `local` as your provider will result in a `sqlite` online store being created.

{% hint style="warning" %}
`feast apply` (when configured to use cloud provider like `gcp` or `aws`) will create cloud infrastructure. This may incur costs.
{% endhint %}

## Entities

List all registered entities

```
feast entities list
```

```
NAME       DESCRIPTION    TYPE
driver_id  driver id      ValueType.INT64
```

## Feature views

List all registered feature views

```
feast feature-views list
```

```
NAME                 ENTITIES
driver_hourly_stats  ['driver_id']
```

## Init

Creates a new feature repository

```
feast init my_repo_name
```

```
Creating a new Feast repository in /projects/my_repo_name.
```

```
.
├── data
│   └── driver_stats.parquet
├── example.py
└── feature_store.yaml
```

It's also possible to use other templates

```
feast init -t gcp my_feature_repo
```

or to set the name of the new project

```
feast init -t gcp my_feature_repo
```

## Materialize

Load data from feature views into the online store between two dates

```bash
feast materialize 2020-01-01T00:00:00 2022-01-01T00:00:00
```

Load data for specific feature views into the online store between two dates

```
feast materialize -v driver_hourly_stats 2020-01-01T00:00:00 2022-01-01T00:00:00
```

```
Materializing 1 feature views from 2020-01-01 to 2022-01-01

driver_hourly_stats:
100%|██████████████████████████| 5/5 [00:00<00:00, 5949.37it/s]
```

## Materialize incremental

Load data from feature views into the online store, beginning from either the previous `materialize` or `materialize-incremental` end date, or the beginning of time.

```
feast materialize-incremental 2022-01-01T00:00:00
```

## Teardown

Tear down deployed feature store infrastructure

```
feast teardown
```

## Version

Print the current Feast version

```
feast version
```
