Cognito Local

A _Good Enough_ offline emulator for Amazon Cognito.

- Supported Features
- Lambda triggers
- Usage
- via Docker
- via Node
- Using a different port
- Updating your application
- Creating your first User Pool
- Configuration
- Custom Email Sender Trigger
- HTTPS endpoints with self-signed certificates
- User Pools and Clients
- Known Limitations
- Multi-factor authentication
- Confirmation codes
- Advanced
- Debugging Cognito Local

Supported Features

| Feature | Support |
| -------------------------------- | -------------------- |
| AddCustomAttributes | ✅ |
| AdminAddUserToGroup | ✅ |
| AdminConfirmSignUp | ✅ |
| AdminCreateUser | 🕒 (partial support) |
| AdminDeleteUser | ✅ |
| AdminDeleteUserAttributes | ✅ |
| AdminDisableProviderForUser | ❌ |
| AdminDisableUser | ✅ |
| AdminEnableUser | ✅ |
| AdminForgetDevice | ❌ |
| AdminGetDevice | ❌ |
| AdminGetUser | ✅ |
| AdminInitiateAuth | 🕒 (partial support) |
| AdminLinkProviderForUser | ❌ |
| AdminListDevices | ❌ |
| AdminListGroupsForUser | ✅ |
| AdminListUserAuthEvents | ❌ |
| AdminRemoveUserFromGroup | ✅ |
| AdminResetUserPassword | ❌ |
| AdminRespondToAuthChallenge | ❌ |
| AdminSetUserMFAPreference | ❌ |
| AdminSetUserPassword | ✅ |
| AdminSetUserSettings | ❌ |
| AdminUpdateAuthEventFeedback | ❌ |
| AdminUpdateDeviceStatus | ❌ |
| AdminUpdateUserAttributes | ✅ |
| AdminUserGlobalSignOut | ❌ |
| AssociateSoftwareToken | ❌ |
| ChangePassword | ✅ |
| ConfirmDevice | ❌ |
| ConfirmForgotPassword | 🕒 (partial support) |
| ConfirmSignUp | 🕒 (partial support) |
| CreateGroup | ✅ |
| CreateIdentityProvider | ❌ |
| CreateResourceServer | ❌ |
| CreateUserImportJob | ❌ |
| CreateUserPool | ✅ |
| CreateUserPoolClient | ✅ |
| CreateUserPoolDomain | ❌ |
| DeleteGroup | ✅ |
| DeleteIdentityProvider | ❌ |
| DeleteResourceServer | ❌ |
| DeleteUser | ✅² |
| DeleteUserAttributes | ✅ |
| DeleteUserPool | ✅² |
| DeleteUserPoolClient | ✅² |
| DeleteUserPoolDomain | ❌ |
| DescribeIdentityProvider | ❌ |
| DescribeResourceServer | ❌ |
| DescribeRiskConfiguration | ❌ |
| DescribeUserImportJob | ❌ |
| DescribeUserPool | ✅ |
| DescribeUserPoolClient | ✅ |
| DescribeUserPoolDomain | ❌ |
| ForgetDevice | ❌ |
| ForgotPassword | 🕒 (partial support) |
| GetCSVHeader | ❌ |
| GetDevice | ❌ |
| GetGroup | ✅² |
| GetIdentityProviderByIdentifier | ❌ |
| GetSigningCertificate | ❌ |
| GetUICustomization | ❌ |
| GetUser | ✅ |
| GetUserAttributeVerificationCode | ✅ |
| GetUserPoolMfaConfig | ✅ |
| GlobalSignOut | ❌ |
| InitiateAuth | 🕒 (partial support) |
| ListDevices | ❌ |
| ListGroups | ✅¹ |
| ListIdentityProviders | ❌ |
| ListResourceServers | ❌ |
| ListTagsForResource | ❌ |
| ListUserImportJobs | ❌ |
| ListUserPoolClients | ✅¹ |
| ListUserPools | ✅¹ |
| ListUsers | ✅¹ |
| ListUsersInGroup | ✅¹ |
| ResendConfirmationCode | ❌ |
| RespondToAuthChallenge | 🕒 (partial support) |
| RevokeToken | 🕒 (partial support) |
| SetRiskConfiguration | ❌ |
| SetUICustomization | ❌ |
| SetUserMFAPreference | ❌ |
| SetUserPoolMfaConfig | ❌ |
| SetUserSettings | ❌ |
| SignUp | 🕒 (partial support) |
| StartUserImportJob | ❌ |
| StopUserImportJob | ❌ |
| TagResource | ❌ |
| UntagResource | ❌ |
| UpdateAuthEventFeedback | ❌ |
| UpdateDeviceStatus | ❌ |
| UpdateGroup | ✅ |
| UpdateIdentityProvider | ❌ |
| UpdateResourceServer | ❌ |
| UpdateUserAttributes | ✅ |
| UpdateUserPool | ✅ |
| UpdateUserPoolClient | ✅² |
| UpdateUserPoolDomain | ❌ |
| VerifySoftwareToken | ❌ |
| VerifyUserAttribute | ✅ |

> ¹ does not support pagination or attribute filters, all results and attributes will be returned in the first request.
>
> ² "requires developer credentials" is not enforced

Additional supported features:

- JWKs verification

$3

cognito-local can emulate Cognito's Lambda Triggers
by either invoking a real Lambda in an AWS account or a Lambda running on your local machine (via any tool which
supports the LambdaInvoke functionality, for example
serverless-offline).

To configure a Lambda Trigger, modify your configuration file to include a TriggerFunctions object
with a key for the Trigger and the value as your Lambda function name.

``json { "TriggerFunctions": { "CustomMessage": "my-function-name" } }`

If you're using local invoke, you will also need to modify the LambdaClient.endpointconfiguration to tell cognito-local how to connect to your local Lambda server:

`json { "LambdaClient": { "endpoint": "http://host:port" }, "TriggerFunctions": { "CustomMessage": "my-local-function-name" } }`

> If you're running cognito-local in Docker and your local Lambda functions on your host, you may need to use the Docker > local networking hostname as your endpoint. For example, on my Mac I usehttp://host.docker.internal:3002.

#### Supported Lambda Triggers

| Trigger | Operation | Support | | --------------------------- | --------------------------------------------- | ------- | | CreateAuthChallenge | \* | ❌ | | CustomEmailSender | CustomEmailSender_SignUp | ✅ | | CustomEmailSender | CustomEmailSender_ResendCode | ✅ | | CustomEmailSender | CustomEmailSender_ForgotPassword | ✅ | | CustomEmailSender | CustomEmailSender_UpdateUserAttribute | ✅ | | CustomEmailSender | CustomEmailSender_VerifyUserAttribute | ✅ | | CustomEmailSender | CustomEmailSender_AdminCreateUser | ✅ | | CustomEmailSender | CustomEmailSender_AccountTakeOverNotification | ❌ | | CustomMessage | AdminCreateUser | ✅ | | CustomMessage | Authentication | ✅ | | CustomMessage | ForgotPassword | ✅ | | CustomMessage | ResendCode | ❌ | | CustomMessage | SignUp | ✅ | | CustomMessage | UpdateUserAttribute | ✅ | | CustomMessage | VerifyUserAttribute | ✅ | | DefineAuthChallenge | \* | ❌ | | PostAuthentication | PostAuthentication_Authentication | ✅ | | PostConfirmation | ConfirmForgotPassword | ✅ | | PostConfirmation | ConfirmSignUp | ✅ | | PreAuthentication | \* | ❌ | | PreSignUp | PreSignUp_AdminCreateUser | ❌ | | PreSignUp | PreSignUp_ExternalProvider | ❌ | | PreSignUp | PreSignUp_SignUp | ✅ | | PreTokenGeneration | TokenGeneration_AuthenticateDevice | ❌ | | PreTokenGeneration | TokenGeneration_Authentication | ✅ | | PreTokenGeneration | TokenGeneration_HostedAuth | ❌ | | PreTokenGeneration | TokenGeneration_NewPasswordChallenge | ❌ | | PreTokenGeneration | TokenGeneration_RefreshTokens | ✅ | | UserMigration | Authentication | ✅ | | UserMigration | ForgotPassword | ❌ | | VerifyAuthChallengeResponse | \* | ❌ |

#### Known limitations

1. Incomplete support for triggers 2. Triggers can only be configured globally and not per-pool

`Usage`

`$3`

docker run --publish 9229:9229 jagregory/cognito-local:latest

Cognito Local will now be listening on http://localhost:9229.

To persist your database between runs, mount the /app/.cognito volume to your host machine:

docker run --publish 9229:9229 --volume $(pwd)/.cognito:/app/.cognito jagregory/cognito-local:latest

`$3`

npm install --save-dev cognito-local yarn add --dev cognito-local

# if node_modules/.bin is in your $PATH cognito-local # OR yarn cognito-local # OR npx cognito-local

Cognito Local will now be listening on http://localhost:9229.

`$3`

cognito-local runs on port 9229 by default. If you would like to use a different port, you can set the PORTenvironment variable:

PORT=4000 cognito-local

If you're running in Docker, you can also rebind the published ports when you run:

docker run -p4000:9229 jagregory/cognito-local

Or combine the two approaches by setting an environment variable when you run:

docker run -p4000:4000 -e PORT=4000 jagregory/cognito-local

The same can be done in docker-compose with environment variables and port binding in compose.

`$3`

You will need to update your AWS code to use the local address for Cognito's endpoint. For example, if you're using amazon-cognito-identity-js you can update yourCognitoUserPool usage to override the endpoint:

`js new CognitoUserPool({ / ... normal options ... / endpoint: "http://localhost:9229/", });`

You only want to do this when you're running locally on your development machine.

`$3`

Once you've started Cognito Local the easiest way to create a new User Pool is with the aws-cli:

`shell aws --endpoint http://localhost:9229 cognito-idp create-user-pool --pool-name MyUserPool`

> Replace the --endpoint with whatever host and port you're running Cognito Local on.

If you run ls .cognito/db you will now see a new file called local_???.json where ??? is the Idfrom the output of the command you just ran.

You may commit this file to version control if you would like all your team to use a common User Pool when developing, or you can have each team member run the above command when they first start using Cognito Local.

> Regarding credentials: the AWS CLI requires credentials to be configured before it will execute any commands > against cognito-local. If you're seeing errors about regions or credentials, make sure you have some kind of AWS > credentials configured in the terminal you're running the aws-cli from. You can use dummy credentials if necessary: >AWS_ACCESS_KEY_ID=123 AWS_SECRET_ACCESS_KEY=123 aws --endpoint http://localhost:9229 cognito-idp ...

`Configuration`

You do not need to supply a config unless you need to customise the behaviour of Cognito Local. If you are using Lambda triggers with local Lambdas, you will definitely need to overrideLambdaClient.endpoint at a minimum.

Before starting Cognito Local, create a config file if one doesn't already exist:

mkdir .cognito && echo '{}' > .cognito/config.json

You can edit that .cognito/config.json and add any of the following settings:

| Setting | Type | Default | Description | |--------------------------------------------|------------|-------------------------|-------------------------------------------------------------| |LambdaClient | object| | Any setting you would pass to the AWS.Lambda Node.js client | |LambdaClient.credentials.accessKeyId | string | local| | |LambdaClient.credentials.secretAccessKey | string | local| | |LambdaClient.endpoint | string | local| | |LambdaClient.region | string | local| | |TokenConfig.IssuerDomain | string | http://localhost:9229| Issuer domain override | |ServerConfig | object| | Any setting you would pass to the Express server | |ServerConfig.hostname | string | localhost| Hostname to listen on | |ServerConfig.port | number | 9229| Port to listen on | |ServerConfig.https | boolean | false| Enable HTTPS | |ServerConfig.ca | string| | Path to the TLS CA file (ServerConfig.https must be true) | |ServerConfig.cert | string| | Path to the TLS Cert file (ServerConfig.https must be true) | |ServerConfig.key | string| | Path to the TLS Key file (ServerConfig.https must be true) | |TriggerFunctions | object | {}| Trigger name to Function name mapping | |TriggerFunctions.CustomMessage | string| | CustomMessage local lambda function name | |TriggerFunctions.PostAuthentication | string| | PostAuthentication local lambda function name | |TriggerFunctions.PostConfirmation | string| | PostConfirmation local lambda function name | |TriggerFunctions.PreSignUp | string| | PostConfirmation local lambda function name | |TriggerFunctions.PreTokenGeneration | string| | PreTokenGeneration local lambda function name | |TriggerFunctions.UserMigration | string| | PreSignUp local lambda function name | |UserPoolDefaults | object| | Default behaviour to use for the User Pool | |UserPoolDefaults.MfaConfiguration | string| | MFA type | |UserPoolDefaults.UsernameAttributes | string[] | ["email"]| Username alias attributes | |KMSConfig | object| | Any setting you would pass to the AWS.KMS Node.js client | |KMSConfig.KMSKeyId | string | local| The KMSKeyId to pass to encrypt the code | |KMSConfig.KMSKeyAlias | string | local| The KMSKeyAlias to pass to encrypt the code | |KMSConfig.credentials.accessKeyId | string | local| | |KMSConfig.credentials.secretAccessKey | string | local| | |KMSConfig.endpoint | string | local| | |KMSConfig.region | string | local | |

The default config is:

`json { "LambdaClient": { "credentials": { "accessKeyId": "local", "secretAccessKey": "local" }, "region": "local" }, "TokenConfig": { "IssuerDomain": "http://localhost:9229" }, "TriggerFunctions": {}, "UserPoolDefaults": { "UsernameAttributes": ["email"] }, "KMSConfig": { "credentials": { "accessKeyId": "local", "secretAccessKey": "local" }, "region": "local" } }`

`$3`

To use a the custom email sender trigger you must provide the KMSKeyID and KMSKeyAliasproperties in theKMSConfig property in the .cognito/config.json file.

One way of setting this up locally is as follows:

You can use the local kms package to simulate a locally running KMS service.

Create a ./local-kms/seed.yml file and populate it with the KMS Key and the KMS Alias:

`yml Keys: Symmetric: Aes: - Metadata: KeyId: bc436485-5092-42b8-92a3-0aa8b93536c BackingKeys: - 5cdaead27fe7da2de47945d73cd6d79e36494e73802f3cd3869f1d2cb0b5d7a9 Aliases: - AliasName: alias/testing TargetKeyId: bc436485-5092-42b8-92a3-0aa8b93536c`

We can use docker-compose to start local-kms:

`yml local-kms: image: nsmithuk/local-kms volumes: - ./local-kms/:/init environment: KMS_ACCOUNT_ID: "999999999" KMS_REGION: "us-west-2"`

This will expose the local-kms service in the docker network at http://local-kms:8080. It will also create a KMS Key with arn:arn:aws:kms:us-west-2:999999999:key/bc436485-5092-42b8-92a3-0aa8b93536cand an KMS Alias with arnarn:aws:kms:us-west-2:999999999:alias/testing.

Now in our cognito-local .cognito/config.json file we just need to populate it with these values:

`yml "TriggerFunctions": { "CustomEmailSender": "your-custom-email-sender-trigger-function-here" }, "KMSConfig": { "KMSKeyId": "arn:aws:kms:us-west-2:999999999:key/bc436485-5092-42b8-92a3-0aa8b93536c", "KMSKeyAlias": "arn:aws:kms:us-west-2:999999999:alias/testing", "endpoint": "http://local-kms:8080" }`

Your custom email sender trigger should now be called with the encrypted code. You can then decrypt it following the AWS documentation. However, make sure to use the samelocal-kms endpoint, KMS Key and KMS Alias when decrypting the code:

`ts const kmsKeyringNode = new kmsSdk.KmsKeyringNode({ generatorKeyId: "arn:aws:kms:us-west-2:999999999:alias/testing", keyIds: [ "arn:aws:kms:us-west-2:999999999:key/bc436485-5092-42b8-92a3-0aa8b93536c", ], clientProvider: () => new AWS.KMS({ endpoint: "http://local-kms:8080" }), });`

`$3`

If you need your Lambda endpoint to be HTTPS with a self-signed certificate, you will need to disable certificate verification in Node for Cognito Local. The easiest way to do this is to run Cognito Local with theNODE_TLS_REJECT_UNAUTHORIZED environment variable.

NODE_TLS_REJECT_UNAUTHORIZED=0 cognito-local docker run --env NODE_TLS_REJECT_UNAUTHORIZED=0 ...

`$3`

User Pools are stored in .cognito/db/$userPoolId.json. As not all API features are supported yet, you'll likely find yourself needing to manually edit this file to update the User Pool config or users. If you do modify this file, you will need to restart Cognito Local.

User Pool Clients are stored in .cognito/db/clients.json. You can create new User Pool Clients using theCreateUserPoolClient API.

`Known Limitations`

- Many features are missing - Users can't be disabled - OnlyUSER_PASSWORD_AUTHflow is supported - Not all Lambda triggers are supported

`Multi-factor authentication`

There is limited support for Multi-Factor Authentication in Cognito Local. Currently, if a User Pool is configured to have aMfaConfiguration of OPTIONAL or ON and a user has an MFAOption of SMSthen Cognito Local will follow the MFA flows. If a user does not have aphone_numberattribute or any other type of MFA is used, Cognito Local will fail.

`Confirmation codes`

When a user is prompted for a code of some kind (confirming their account, multi-factor auth), Cognito Local will write a message to the console with their confirmation code instead of emailing it to the user.

For example:

`╭───────────────────────────────────────────────────────╮ │ │ │ Confirmation Code Delivery │ │ │ │ Username: c63651ae-59c6-4ede-ae7d-a8400ff65e8d │ │ Destination: example@example.com │ │ Code: 3520 │ │ │ ╰───────────────────────────────────────────────────────╯`

If a Custom Message lambda is configured, the output of the function invocation will be printed in the console too (verbosely!).

By default, confirmation codes are randomly generated. If set, the value assigned to the CODE environment variable will always be returned instead.

`Advanced`

`$3`

There's a few different ways you can debug Cognito Local. _Currently, it's best to debug Cognito Locally via Node, and not with Docker_.

#### Verbose logging

If you just need more logs to understand what Cognito Local is doing, you can use the DEBUG environment variable.

`shell DEBUG=1 yarn start`

Which will print extra debug logs to the terminal (with {...} replaced by detailed information):

`[1639034724411] INFO: NONE NONE Cognito Local running on http://127.0.0.1:9229 [1639034724872] DEBUG: 7f53abbd CreateUserPool start {...} [1639034724873] DEBUG: 7f53abbd CreateUserPool CognitoServiceImpl.createUserPool {...} [1639034724873] DEBUG: 7f53abbd CreateUserPool UserPoolServiceImpl.create {...} [1639034724873] DEBUG: 7f53abbd CreateUserPool createDataStore {...} [1639034724873] DEBUG: 7f53abbd CreateUserPool Creating new data store {...} [1639034724874] DEBUG: 7f53abbd CreateUserPool DataStore.save {...} [1639034724876] DEBUG: 7f53abbd CreateUserPool DataStore.get {...} [1639034724877] DEBUG: 7f53abbd CreateUserPool end {...} [1639034724882] DEBUG: 7f53abbd NONE request completed {...}`

#### VSCode debugger

There's a launch configuration included in the repo at .vscode/launch.json.

If you open Run and Debug and start the CognitoLocalconfiguration it will start Cognito Local and attach the debugger.

Put a breakpoint in src/bin/start.ts or in the target for the API call you want to debug (e.g. src/targets/createUserPool.ts) and run your code that uses Cognito Local or a CLI command.

#### WebStorm debugger

There's a WebStorm run configuration included in the repo at .idea/runConfigurations/CognitoLocal.xml.

A CognitoLocalentry should appear in the Run Configurations drop-down in the toolbar, which you can Run or Debug. Alternatively, theRun > Debug menu will let you pick a Run Configuration to launch.

Put a breakpoint in src/bin/start.ts or in the target for the API call you want to debug (e.g. src/targets/createUserPool.ts) and run your code that uses Cognito Local or a CLI command.

#### Chrome DevTools

> Note: due to a poor choice of ports on my part, Chrome will spam Cognito Local with HTTP requests if you have the > NodeJS DevTools open. I'll change the default port for Cognito Local at some point to fix this.

Launch Cognito Local using the start:debug script:

`shell yarn start:debug`

This will configure NodeJS to start the inspector on port 9230.

Open Chrome and navigate to chrome://inspect. Click the Open dedicated DevTools for Nodelink which will open a new DevTools window. You can then open the Sources tab and browse to a Cognito Local file, or pressCmd+P or Ctrl+Pto open the file navigator and opensrc/bin/start.ts` or a target you want to debug then place a breakpoint and run your
code that uses Cognito Local or a CLI command.

Cognito Local

!CI

A _Good Enough_ offline emulator for Amazon Cognito.

Supported Features

> ¹ does not support pagination or attribute filters, all results and attributes will be returned in the first request.
>
> ² "requires developer credentials" is not enforced

Additional supported features:

- JWKs verification

$3

To configure a Lambda Trigger, modify your configuration file to include a TriggerFunctions object
with a key for the Trigger and the value as your Lambda function name.

``json { "TriggerFunctions": { "CustomMessage": "my-function-name" } }`

If you're using local invoke, you will also need to modify the LambdaClient.endpointconfiguration to tell cognito-local how to connect to your local Lambda server:

`json { "LambdaClient": { "endpoint": "http://host:port" }, "TriggerFunctions": { "CustomMessage": "my-local-function-name" } }`

#### Supported Lambda Triggers

#### Known limitations

1. Incomplete support for triggers 2. Triggers can only be configured globally and not per-pool

`Usage`

`$3`

docker run --publish 9229:9229 jagregory/cognito-local:latest

Cognito Local will now be listening on http://localhost:9229.

To persist your database between runs, mount the /app/.cognito volume to your host machine:

docker run --publish 9229:9229 --volume $(pwd)/.cognito:/app/.cognito jagregory/cognito-local:latest

`$3`

npm install --save-dev cognito-local yarn add --dev cognito-local

# if node_modules/.bin is in your $PATH cognito-local # OR yarn cognito-local # OR npx cognito-local

Cognito Local will now be listening on http://localhost:9229.

`$3`

cognito-local runs on port 9229 by default. If you would like to use a different port, you can set the PORTenvironment variable:

PORT=4000 cognito-local

If you're running in Docker, you can also rebind the published ports when you run:

docker run -p4000:9229 jagregory/cognito-local

Or combine the two approaches by setting an environment variable when you run:

docker run -p4000:4000 -e PORT=4000 jagregory/cognito-local

The same can be done in docker-compose with environment variables and port binding in compose.

`$3`

`js new CognitoUserPool({ / ... normal options ... / endpoint: "http://localhost:9229/", });`

You only want to do this when you're running locally on your development machine.

`$3`

Once you've started Cognito Local the easiest way to create a new User Pool is with the aws-cli:

`shell aws --endpoint http://localhost:9229 cognito-idp create-user-pool --pool-name MyUserPool`

> Replace the --endpoint with whatever host and port you're running Cognito Local on.

If you run ls .cognito/db you will now see a new file called local_???.json where ??? is the Idfrom the output of the command you just ran.

`Configuration`

Before starting Cognito Local, create a config file if one doesn't already exist:

mkdir .cognito && echo '{}' > .cognito/config.json

You can edit that .cognito/config.json and add any of the following settings:

The default config is:

`$3`

To use a the custom email sender trigger you must provide the KMSKeyID and KMSKeyAliasproperties in theKMSConfig property in the .cognito/config.json file.

One way of setting this up locally is as follows:

You can use the local kms package to simulate a locally running KMS service.

Create a ./local-kms/seed.yml file and populate it with the KMS Key and the KMS Alias:

We can use docker-compose to start local-kms:

`yml local-kms: image: nsmithuk/local-kms volumes: - ./local-kms/:/init environment: KMS_ACCOUNT_ID: "999999999" KMS_REGION: "us-west-2"`

Now in our cognito-local .cognito/config.json file we just need to populate it with these values:

`$3`

NODE_TLS_REJECT_UNAUTHORIZED=0 cognito-local docker run --env NODE_TLS_REJECT_UNAUTHORIZED=0 ...

`$3`

User Pool Clients are stored in .cognito/db/clients.json. You can create new User Pool Clients using theCreateUserPoolClient API.

`Known Limitations`

- Many features are missing - Users can't be disabled - OnlyUSER_PASSWORD_AUTHflow is supported - Not all Lambda triggers are supported

`Multi-factor authentication`

`Confirmation codes`

For example:

If a Custom Message lambda is configured, the output of the function invocation will be printed in the console too (verbosely!).

By default, confirmation codes are randomly generated. If set, the value assigned to the CODE environment variable will always be returned instead.

`Advanced`

`$3`

There's a few different ways you can debug Cognito Local. _Currently, it's best to debug Cognito Locally via Node, and not with Docker_.

#### Verbose logging

If you just need more logs to understand what Cognito Local is doing, you can use the DEBUG environment variable.

`shell DEBUG=1 yarn start`

Which will print extra debug logs to the terminal (with {...} replaced by detailed information):

#### VSCode debugger

There's a launch configuration included in the repo at .vscode/launch.json.

If you open Run and Debug and start the CognitoLocalconfiguration it will start Cognito Local and attach the debugger.

Put a breakpoint in src/bin/start.ts or in the target for the API call you want to debug (e.g. src/targets/createUserPool.ts) and run your code that uses Cognito Local or a CLI command.

#### WebStorm debugger

There's a WebStorm run configuration included in the repo at .idea/runConfigurations/CognitoLocal.xml.

Put a breakpoint in src/bin/start.ts or in the target for the API call you want to debug (e.g. src/targets/createUserPool.ts) and run your code that uses Cognito Local or a CLI command.

#### Chrome DevTools

Launch Cognito Local using the start:debug script:

`shell yarn start:debug`

This will configure NodeJS to start the inspector on port 9230.