Best practices

Delivery

• Log in and enable watching on selected apps to push metrics, logs, and events to your dashboard; build/run works without either.
• Use meaningful, unique names for your applications.
• Tag important builds (e.g. --tag "v2.1-release") for easier rollback identification.
• Review rollback --list before restoring a build.
• Preview destructive rollbacks with --dry-run before executing - especially for production rollbacks, large rollback distances (many versions behind), tagged-release rollbacks, rollbacks after a failed deployment, and blue-green/rolling apps where the traffic transition matters:

  phelix rollback myapp --to stable --dry-run   # inspect the planphelix rollback myapp --to stable             # then execute

• Keep the proxy daemon running (phelix proxy) for zero-downtime deployments and rollbacks.
• Check phelix status <app> for version history before deciding to roll back.
• Use matrix dry runs before large multi-platform builds.
• Use phelix dockerize to containerize apps with optimized, cached Dockerfiles.

Observability

• Monitor application logs (phelix log) for debugging.
• Check application health regularly with phelix status.
• Provide a real readiness endpoint for Tier 1 checks.
• Set a --mode that matches your app: http for servers, tcp-only for bare ports, none for daemons.
• Watch the automatic Build Report after every build - it is the fastest way to detect unexpected binary growth, compilation regressions, or toolchain changes.
• Treat repeated duration regressions in the same cache mode as a signal: if cold builds keep getting slower across versions, the codebase - not the cache - is the problem.
• Use phelix build-report <AppName> to review stored build history before investigating a performance or size issue; it is read-only and works offline.
• After a matrix build, check each combination's summary - a size regression in one platform/toolchain combination won't show up in the others.
• Watch RAM and CPU usage across all servers.
• Ensure proper network connectivity between servers.
• Review rollback audit logs after recovery events.

Security

• Use encrypted environment variables for sensitive data (API keys, database credentials, and similar).
• Never commit master keys or encrypted env files to version control.
• Regularly rotate sensitive credentials.
• Use descriptive variable names (for example DATABASE_CONNECTION_URL instead of DB).
• Restrict permissions on sensitive files - the master key ships with 0600.