Build a Safe Practice Environment

Learning is faster when experiments cannot damage a live domain or expose private data.

Separate Four Environments

Notebook -> Local files -> Local web server -> Public production server

Each step should work before the next one begins.

Notebook

Contains plans, expected values, change records, and rollback notes. It stays private.

Local files

Contains the website source. It can be version controlled and reviewed without running a server.

Local web server

Serves the files on 127.0.0.1 so only the local machine can connect.

Public production server

Receives internet traffic. It requires updates, a firewall, backups, monitoring, and incident ownership.

Create the Workspace

mkdir -p domain-book-project/{site,notes,backups}
cd domain-book-project

Recommended layout:

domain-book-project/
├── backups/
├── notes/
│   ├── changes.md
│   └── inventory.md
└── site/
    ├── assets/
    └── index.html

The backups directory here is only a staging location. A real backup must also exist on another system or storage boundary.

Initialize Version Control

git init
git status

Create .gitignore:

.DS_Store
.env
*.log
backups/
notes/private-*

Ignored files are not encrypted. Anyone with filesystem access may still read them.

Use a Fictional Configuration First

Create notes/inventory.md:

# Infrastructure Inventory

- Domain: example.dpdns.org
- IPv4: 192.0.2.10
- IPv6: 2001:db8::10
- Nameserver: ns1.dns-service.example
- Environment: practice only

This prevents accidental instructions from targeting a real system during early experiments.

Define a Change Record

Create notes/changes.md:

# Change Log

## Template

- Date and time:
- Operator:
- Goal:
- Current value:
- Intended value:
- Verification:
- Rollback:
- Result:

Local Safety Checks

Before running a local server:

pwd
find site -maxdepth 2 -type f -print

Before publishing source:

git status --short
git diff --cached
rg -n -i 'password|secret|token|api[_-]?key' .

Search results are prompts for review, not proof that every matching line is a secret or that every secret was found.

Use a Test Hostname

If you later need a public test, create an explicit subdomain such as lab.example.dpdns.org. Do not point the main public hostname at an unfinished environment.

Protect test environments. A hostname containing test is still publicly reachable when DNS and firewall rules expose it.

Snapshot Before Risky Work

Before changing a server or zone:

• Export DNS records.
• Copy web server configuration.
• Record package versions.
• Back up website files and application data.
• Test that the backup can be read.
• Write the exact rollback commands.

Exit Criteria

You are ready for Part 1 when:

• You have a private notebook.
• You can identify the current directory in a terminal.
• You know which files are public website files.
• You can distinguish fictional examples from real values.
• You have written at least one change record without making a public change.

Continue to Plan Your First Website.