Support Tilt for local development

[JacobCoffee]

I find myself needing multiple services when working across projects and ports almost always conflict (i.e., working on warehouse + pycon-site + pycon check in + python.org) whether that be conflicting on the web service, database, or otherwise.

In comes Tilt, which allows us to more accurately reflect production deployments and avoid this port conflict

When bootstrapped with a local cabotage instance it will generate a URL based on ingress IP. I'm using nip.io (https://sslip.io/) to help with some DNS issues. (but maybe it's not needed)

[miketheman]

Instead of the addition of Tilt, would it make more sense to reduce the amount of "public" ports we expose by default? I think most of them like pg and stripe don't need to be host-facing.

[JacobCoffee]

@miketheman yeah we could remove these from the docker-compose and just let them talk overt docker network i guess. we could also do both, as tilt gives us some dev/prod parity which is why i like it for python.org and other apps i'm working on

In general, to fix clear-text logging of sensitive information, avoid sending any data derived from secrets (even metadata like counts, names, or partial values) to logs. If progress needs to be logged, restrict it to non-secret information or to fixed, non–data-dependent messages.

Here, the specific issue is that secrets_count = len(app_config.get("secrets", {})) is then interpolated into a log line. The simplest fix without changing functionality is to stop including the secret-derived count in the log message while still logging the env var count, or to remove the line entirely. The functional behavior of the script (creating/updating configs and committing them) does not depend on this log line; it is purely informational.

Best minimal change in scripts/bootstrap_cabotage.py:

• Keep computation of env_count if we still want to log it.
• Either:
  • Keep secrets_count for internal use but do not log it, or
  • Remove secrets_count entirely (since it’s only used for logging).
• Change the log line to avoid interpolating secrets_count and instead use a generic message like " Synced environment and secrets configuration" or a format that only mentions the env var count, e.g., " Synced {env_count} env vars and secrets" (no count for secrets).

Since secrets_count is not used anywhere else, the cleanest fix is to remove it and update the print accordingly. No new imports or helper methods are required.

Concretely:

• Around lines 362–365, remove the assignment to secrets_count and change the print so that it does not include {secrets_count}. Everything else in the file remains unchanged.