We can use the `inngest run` command to execute your function locally against generated event payloads, specific events from the past, or a number of recent events.

We make it easy to test your function locally, not just against dummy data but also **real production data** in your dev environment. This functionality helps identify potential breaking changes _before_ you make them or gives you confidence that a dangerous change does indeed still work.

## Run your function with dummy data

In its most basic form, you can use `inngest run` to run your function locally against dummy data generated from your event's schema.

```sh
$ inngest run
```

Here, the CLI uses the event triggers defined in the [`inngest.json|cue`](/docs/functions/inngest-json-configuration) file and generates fake events based on the schema.

<aside>
 
 Tip: Provide <code>--seed [integer]</code> to generate an event with the same data repeatedly.
 
</aside>

Dummy data is excellent for testing that your function handles the incoming schema but may not be ideal for functions with many conditional steps, where your actual data shines.



<details>
 <summary>See it in action</summary>

 ![Running a function with a generated event](/assets/docs/inngest-run/replay-generated.gif)
</details>

## Replay past events

The true power of `inngest run` is the ability to replay past events from either your production or test workspaces.

```sh
$ inngest run --replay
```


Replaying is incredibly useful to ensure that a change to a function works as expected or when creating brand new functions based on existing events in your ecosystem. You can be sure your functions will run as expected in production without code ever leaving your machine.


<aside>
 
 Tip: By default, we'll look for events from your test workspace. Add <code>--prod</code> to replay events from your production workspace instead.
 
</aside>

<details>
 <summary>See it in action</summary>

 ![Running a function with past events](/assets/docs/inngest-run/replay-past.gif)
</details>

Replaying provides a couple of extra flags for customising the events that will be run.

Note that currently, if your function reacts to more than one [trigger](/docs/functions/introduction#the-trigger), you must provide which trigger you want to replay using `--trigger [my-trigger]`

```sh
# Run your function with the last 20 events
$ inngest run --replay [-c/--count] 20

# Run your function with recent events from a specific trigger
$ inngest run --replay [-t/--trigger] stripe/customer.created

# Show input and output for each event and step
$ inngest run --replay --verbose
```

## Replay a specific event



If you find an event causing problems for your function - or where the output wasn't quite as expected - you can choose to replay that specific event to ensure that the code change you're making will fix the issue.


No more testing in production! 🥳




```sh
$ inngest run --replay --event-id 01G8BG4FT7CZVAD38D4RJNGTT1
```

<details>
 <summary>See it in action</summary>

 ![Running a function with a specific event](/assets/docs/inngest-run/replay-specific.gif)
</details>

## Run with local data

Events are [always JSON](/docs/event-format-and-structure), meaning it's easy to save an event's data locally and use it when testing via `inngest run`.

Pipe a JSON event (or an array of JSON events) into the command to run your functions with that data.

```sh
$ cat snapshot.json | inngest run
```

<details>
 <summary>See it in action</summary>

 ![Running a function with snapshot data](/assets/docs/inngest-run/replay-snapshot.gif)
</details>

You can create a snapshot by adding the `--snapshot` flag to any of the above commands, for example:

```sh
# Snapshot the last 20 events
$ inngest run --replay -c 20 --snapshot > snapshot.json

# Snapshot 5 generated events
$ inngest run -c 5 --snapshot > snapshot.json

# Snapshot a single known problem event
$ inngest run --replay --event-id 01G8BG4FT7CZVAD38D4RJNGTT1 --snapshot
```

<aside>
 
 Tip: When creating a new function, snapshot some dummy data using <code>inngest run --snapshot</code>, then edit the created JSON to provide realistic local use cases.
 
</aside>

`run`

Replay a specific event

Replay past events

Run with local data

Run your function with dummy data

`init`

Usage

Once you've built and locally tested your function it's time to deploy it to the cloud.

Deploying your function will automatically build each step, push the code to Inngest,
and create a new version of the function. Inngest will automatically run this new
version every time matching events are received.

Read on to learn about:

- Test and production environments
- How to deploy functions

## Environments

Inngest comes with both a test and production environment out of the box. This allows
you to deploy functions safely without affecting your customers, then promote and deploy
to production when it's ready.

## Running deploy

You can deploy functions by running `inngest deploy`. By default this deploys
to the test environment. You can deploy to production via:

```sh
# deploy all functions in the local directory, recursively, to prod.
inngest deploy --prod .
```

This will package and ship all functions to production, setting them live instantly.

Deploying functions

Environments

Running deploy