Operate
Known environments and installations
Track which Buffaly environments exist, what they are for, and how to validate that you are working in the right place.
Environment records
An environment record should help a user or operator distinguish one installation from another.
- Record the base URL, purpose, owner, and expected data root.
- Name the application or service hosted there and the safest non-secret identifier for that instance.
- Note whether the environment is local, staging, public, or customer-specific.
- Summarize how the instance is built, started, updated, and verified without exposing machine-specific private paths.
- Keep credentials out of public docs and store only the key or retrieval method when appropriate.
Choosing the right target
Most operational mistakes come from working against the wrong environment.
- Confirm the URL and repository before making changes.
- Check which data stores and provider credential names the installation depends on, but do not copy credential contents into the environment page.
- Check whether the task affects docs, runtime behavior, data, or deployment artifacts.
- Call out actions that are risky or restricted, such as deployment, database changes, credential rotation, billing changes, or public availability changes.
- Ask Buffaly to verify the target with file paths, route checks, or service status before editing.
Verification routine
Before asking Buffaly to inspect, edit, or deploy an installation, capture enough evidence to prove which environment is active.
For a local install
- Check the repository root and project file path before running commands.
- Open the expected local URL and one known docs route.
- Confirm logs, session data, and temp folders point to the same installation.
For a shared or public install
- Confirm the hostname, release branch, and deployment owner.
- Use non-secret environment labels instead of copying credentials into notes.
- Record the exact route, timestamp, and validation result in the task history.
If any of these checks disagree, stop and resolve the target mismatch before making a change. A clean build in one checkout does not validate a different installed site.
Validation
Each environment should have a small validation path.
- Open a known route after deployment or local launch.
- Check logs when a route fails or returns stale content.
- Record the validation result in the task or release notes.