This is a reference/teaching architecture under active development. Only the latest commit on the default branch is actively maintained. If you depend on it, pin to a specific commit or tag.

Please do not open a public issue for security vulnerabilities. Instead, report privately so it can be addressed before disclosure.

To report a vulnerability, contact the maintainers via a private channel (e.g. a GitHub private security advisory or a direct email to the maintainer recorded in the project). Include:

• A description of the vulnerability.
• The affected component and version/commit.
• Steps to reproduce (if possible).
• Any proposed fix.

You should receive a response within a reasonable timeframe. Please allow time for a fix before public disclosure.

This project is a local-development / educational data stack. It is not designed to be exposed to the public internet without hardening. Please follow the guidance below.

• Secrets are not committed. All credentials are injected at runtime from a git-ignored .env file. A .env.example template documents every variable.
• Private object storage. The MinIO warehouse and mlflow buckets are created private on startup (no public mc policy set public is issued).
• Minimal port exposure. Only the UI/API ports needed for use are published to the host; back-end stores talk over the internal Docker network.

1. Rotate all defaults. Replace every value in .env (database passwords, MinIO root credentials, Jupyter token, Superset secret key) before any shared or persistent deployment. The defaults in .env.example are placeholders.
2. Keep .env out of VCS. It is git-ignored. Never force-add or commit it.
3. If you change MinIO credentials, synchronize the S3 keys in trino_config/catalog/nessie.properties.
4. Do not expose the stack publicly without TLS, authentication, and network segmentation. Services such as Trino, Metabase-style endpoints, and the object store should sit behind a firewall / VPN and, ideally, a reverse proxy.
5. Prebuilt production images. The Prefect container installs packages and registers flows on startup. For production, build dedicated images with pinned dependencies and separate the server from flow deployments.

These exist only to make a local demo frictionless and must be changed before any deployment beyond a sandbox.