How much does zuzu.codes cost?

The starter track is free — read all lessons and practice for free. Full access to every track (current and future) is $14.99/month. Cancel anytime.

How long does each track take?

Each track is designed as a 30-day challenge — one lesson per day, about 15 minutes each. Go at your own pace, but the structure is built around daily consistency.

What's the lesson format?

Each lesson is a student-teacher dialogue with code examples, followed by a hands-on code challenge in an in-browser editor. You read, you understand, then you write real code.

Do I need prior coding experience?

Our beginner track starts from absolute zero — no prior experience needed. Advanced tracks build on earlier ones, and the platform tells you exactly where to start.

How is zuzu.codes different from freeCodeCamp or Codecademy?

zuzu.codes uses a structured 30-day track format with dialogue-based teaching, an in-browser code editor, and gamification (XP, streaks, progress tracking). The format builds genuine understanding through daily practice.

Per-environment config — Automation Mastery

Day 13 · ~11 min●

A script that runs against the same endpoint and same credentials in dev and in production is a script that will eventually email your real users from your dev box. Separate the two.

python

import os

CONFIGS = {
    "dev": {
        "api_url": "https://api-staging.example.com",
        "sender": "dev-test@example.com",
    },
    "prod": {
        "api_url": "https://api.example.com",
        "sender": "alerts@example.com",
    },
}

env = os.environ.get("ENV", "dev")
config = CONFIGS[env]
print(f"selected config: {env}")

Why default to dev?

Fail safe. A missing or misspelled ENV should land you in dev — emails go to your test address, no real customer is touched. Defaulting to prod would be the opposite: misconfigured = production blast.

For very sensitive operations (payment captures, data deletion), some teams go further: refuse to run when ENV isn't set explicitly. os.environ["ENV"] (raise on missing) is the right reflex there.

And what's typically in a config block?

API URL. Sender address (so dev emails come from a different address). Database connection string. Feature flags (enable_new_dispatcher: false in prod for now). Logging verbosity (debug in dev, info in prod). Anything that's environment-specific, not secret-specific.

Per-environment config — separate dev and prod

Why separate

A script with one set of credentials and one set of endpoints will eventually do prod work from dev:

You hit "run" on your laptop while testing
Your script writes to the real Sheet, emails real users, charges real cards
You discover the mistake during the post-mortem

The fix is configuration that flips between dev and prod based on a single env var.

The pattern

python

import os

CONFIGS = {
    "dev": {
        "api_url": "https://api-staging.example.com",
        "sender": "dev-test@example.com",
        "sheet_name": "Sheet1-dev",
        "log_level": "DEBUG",
    },
    "prod": {
        "api_url": "https://api.example.com",
        "sender": "alerts@example.com",
        "sheet_name": "Sheet1",
        "log_level": "INFO",
    },
}

env = os.environ.get("ENV", "dev")
if env not in CONFIGS:
    raise RuntimeError(f"unknown ENV: {env}")
config = CONFIGS[env]

What goes in config (vs in env vars directly)

Belongs in `CONFIGS` dict	Belongs in env vars
URLs (no credentials)	API keys, tokens
Sender addresses	Database passwords
Feature flags	Webhook signing secrets
Sheet/document names	Anything sensitive
Log levels	(rule of thumb: if it would be a problem to commit to git, it's a secret)

The rule: secrets in env vars (different value per environment, set by deployment); non-secret config in code (same dict checked in, key chosen by ENV).

Default to safe (dev)

python

env = os.environ.get("ENV", "dev")    # safe default

vs.

python

env = os.environ.get("ENV", "prod")   # WRONG — misconfigured = production

If the env var is missing or misspelled, dev is the safer landing spot.

Prod-only confirmations

For irreversible operations (sending real email, charging cards), add an extra check:

python

if env == "prod":
    confirm = os.environ.get("CONFIRM_PROD")
    if confirm != "yes":
        raise RuntimeError("prod operation requires CONFIRM_PROD=yes")

Forces a deliberate decision before the script touches production state.

Beyond two environments

Larger systems have more: dev / staging / prod-eu / prod-us. Same pattern, more keys in the dict. Some teams use a single ENV=staging with config layered as defaults → staging → prod-eu overrides — the dict-of-dicts grows into a small layered config system. For most scripts, a flat CONFIGS[env] is enough.

Day 13 · ~11 min●

A script that runs against the same endpoint and same credentials in dev and in production is a script that will eventually email your real users from your dev box. Separate the two.

python

import os

CONFIGS = {
    "dev": {
        "api_url": "https://api-staging.example.com",
        "sender": "dev-test@example.com",
    },
    "prod": {
        "api_url": "https://api.example.com",
        "sender": "alerts@example.com",
    },
}

env = os.environ.get("ENV", "dev")
config = CONFIGS[env]
print(f"selected config: {env}")

Why default to dev?

And what's typically in a config block?

Per-environment config — separate dev and prod

Why separate

A script with one set of credentials and one set of endpoints will eventually do prod work from dev:

You hit "run" on your laptop while testing
Your script writes to the real Sheet, emails real users, charges real cards
You discover the mistake during the post-mortem

The fix is configuration that flips between dev and prod based on a single env var.

The pattern

python

import os

CONFIGS = {
    "dev": {
        "api_url": "https://api-staging.example.com",
        "sender": "dev-test@example.com",
        "sheet_name": "Sheet1-dev",
        "log_level": "DEBUG",
    },
    "prod": {
        "api_url": "https://api.example.com",
        "sender": "alerts@example.com",
        "sheet_name": "Sheet1",
        "log_level": "INFO",
    },
}

env = os.environ.get("ENV", "dev")
if env not in CONFIGS:
    raise RuntimeError(f"unknown ENV: {env}")
config = CONFIGS[env]

What goes in config (vs in env vars directly)

Belongs in `CONFIGS` dict	Belongs in env vars
URLs (no credentials)	API keys, tokens
Sender addresses	Database passwords
Feature flags	Webhook signing secrets
Sheet/document names	Anything sensitive
Log levels	(rule of thumb: if it would be a problem to commit to git, it's a secret)

The rule: secrets in env vars (different value per environment, set by deployment); non-secret config in code (same dict checked in, key chosen by ENV).

Default to safe (dev)

python

env = os.environ.get("ENV", "dev")    # safe default

vs.

python

env = os.environ.get("ENV", "prod")   # WRONG — misconfigured = production

If the env var is missing or misspelled, dev is the safer landing spot.

Prod-only confirmations

For irreversible operations (sending real email, charging cards), add an extra check:

python

if env == "prod":
    confirm = os.environ.get("CONFIRM_PROD")
    if confirm != "yes":
        raise RuntimeError("prod operation requires CONFIRM_PROD=yes")

Forces a deliberate decision before the script touches production state.

Per-environment config — separate dev and prod

Why separate

The pattern

What goes in config (vs in env vars directly)

Default to safe (dev)

Prod-only confirmations

Beyond two environments

Per-environment config — separate dev and prod

Why separate

The pattern

What goes in config (vs in env vars directly)

Default to safe (dev)

Prod-only confirmations

Beyond two environments

Per-environment config — separate dev and prod

Why separate

The pattern

What goes in config (vs in env vars directly)

Default to safe (dev)

Prod-only confirmations

Beyond two environments

Sign up to practice

Per-environment config — separate dev and prod

Why separate

The pattern

What goes in config (vs in env vars directly)

Default to safe (dev)

Prod-only confirmations

Beyond two environments

Sign up to practice