Account, Region, CLI, and Stack Setup

Now that the platform vocabulary is in place, it is time to create the working foundation Veda expects: an account, the right region, a seeded stack, and the tokens your local app will use.

What you'll learn

• Which account and stack setup path this guide assumes

• Why region selection matters early

• How to install the Contentstack CLI and log in

• How to seed the Veda stack content

• Which tokens and environment variables the Veda app expects

• Which values are safe to expose in the browser and which are not

Start with the right account mindset

Contentstack concept: You do not need an enterprise rollout to learn Contentstack well. The Quick Start and Veda materials are designed to work with the platform's accessible onboarding paths, including Explorer-oriented flows.

That is useful because it means you can learn the platform in a realistic way without inventing your own seed data from scratch.

Region matters sooner than most people expect

Contentstack concept: Your region determines which endpoints your app and tools should talk to.

This affects:

• CLI configuration

• delivery hosts

• preview hosts

• sometimes the exact values or aliases used in environment variables

The official Quick Start currently shows a provider-prefixed CLI region example:

csdx config:set:region EU

Production note: If your installed CLI rejects one form, check csdx --help or the current CLI guidance and use the value it expects. The important part is not the exact alias. The important part is that the CLI and your stack region agree.

Install the CLI

Contentstack concept: The CLI is the fastest way to bootstrap a working stack for learning and demos.

Install it globally:

npm install -g @contentstack/cli

Then configure your region and log in:

csdx config:set:region EU
csdx auth:login

If your CLI expects a provider-prefixed region value, use that instead.

Seed the Veda stack

Veda implementation: The current Veda setup path uses a seed repository so you do not have to manually create every content type and entry.

Use the seed command from the Veda setup flow:

csdx cm:stacks:seed --repo "contentstack/kickstart-veda-seed" --org "<YOUR_ORG_ID>" -n "Veda: The Revival Collection"

What this gives you:

• the content model

• starter entries

• assets

• the content relationships the frontend expects

Without the seed, the frontend can still run, but you would first need to recreate the full content structure by hand.

Create the right tokens

Contentstack concept: The frontend needs read-oriented credentials, not administrative ones.

For Veda, create:

• an API key for the stack

• a delivery token for published content

• a preview token for draft content and preview flows

In the Veda setup instructions, this is done from the Contentstack dashboard under Settings and Tokens.

Production note: Do not use a management token in a frontend app. If you ever need write access, keep it on a server or inside controlled automation.

Configure local environment variables

Veda implementation: The checked-in .env.example in the Veda repository currently uses these variables:

NEXT_PUBLIC_CONTENTSTACK_API_KEY=your_api_key_here
NEXT_PUBLIC_CONTENTSTACK_DELIVERY_TOKEN=your_delivery_token_here
NEXT_PUBLIC_CONTENTSTACK_PREVIEW_TOKEN=your_preview_token_here
NEXT_PUBLIC_CONTENTSTACK_ENVIRONMENT=preview
NEXT_PUBLIC_CONTENTSTACK_REGION=EU
NEXT_PUBLIC_CONTENTSTACK_PREVIEW=true

Two details matter here:

1. The variables use NEXT_PUBLIC_ because Veda's preview experience needs values on the client side

2. The app distinguishes between published delivery and preview behavior using NEXT_PUBLIC_CONTENTSTACK_PREVIEW

Why Veda uses public-looking variables

Veda implementation: In many apps, developers are taught to avoid exposing anything that looks credential-like to the browser. That is a good instinct, but you still need to separate categories of credentials.

Veda uses:

• delivery token

• preview token

• API key

These support content delivery and preview behavior. They are not the same thing as a management token.

Production note: The rule is not "never expose any token-looking string." The rule is "never expose privileged write credentials." Read-only delivery and preview credentials have a different security profile than content administration credentials.

Recommended setup sequence

If you want the path of least resistance, do it in this order:

1. Create or access a Contentstack account

2. Install the CLI

3. Set the correct region

4. Log in

5. Seed the Veda stack

6. Create delivery and preview tokens

7. Prepare your .env.local values for the app

That keeps the frontend setup simple, because once you clone Veda you already know the stack exists and the credentials are ready.

Key takeaways

• Region matters for both CLI behavior and runtime endpoints

• The Veda learning path is much easier if you seed the stack instead of hand-building the content model first

• The Veda app expects delivery and preview credentials, plus an API key and environment name

• NEXT_PUBLIC_ variables in Veda support preview-aware frontend behavior

• Management credentials are a different class of secret and should stay off the frontend