## File: README.md # The Bitnami Containers Library Popular applications, provided by [Bitnami](https://bitnami.com), containerized and ready to launch. ## Why use Bitnami Secure Images? Those are hardened, minimal CVE images built and maintained by Bitnami. Bitnami Secure Images are based on the cloud-optimized, security-hardened enterprise [OS Photon Linux](https://vmware.github.io/photon/). Why choose BSI images? - Hardened secure images of popular open source software with Near-Zero Vulnerabilities - Vulnerability Triage & Prioritization with VEX Statements, KEV and EPSS Scores - Compliance focus with FIPS, STIG, and air-gap options, including secure bill of materials (SBOM) - Software supply chain provenance attestation through in-toto - First class support for the internet’s favorite Helm charts Each image comes with valuable security metadata. You can view the metadata in [our public catalog here](https://app-catalog.vmware.com/bitnami/apps). Note: Some data is only available with [commercial subscriptions to BSI](https://bitnami.com/). If you are looking for our previous generation of images based on Debian Linux, please see the [Bitnami Legacy registry](https://hub.docker.com/u/bitnamilegacy). ## Get an image The recommended way to get any of the Bitnami Images is to pull the prebuilt image from the [Docker Hub Registry](https://hub.docker.com/r/bitnami/). ```console docker pull bitnami/APP ``` To use a specific version, you can pull a versioned tag. ```console docker pull bitnami/APP:[TAG] ``` If you wish, you can also build the image yourself by cloning the repository, changing to the directory containing the Dockerfile, and executing the `docker build` command. ```console git clone https://github.com/bitnami/containers.git cd bitnami/APP/VERSION/OPERATING-SYSTEM docker build -t bitnami/APP . ``` > [!TIP] > Remember to replace the `APP`, `VERSION`, and `OPERATING-SYSTEM` placeholders in the example command above with the correct values. ## Run the application using Docker Compose The main folder of each application contains a functional `docker-compose.yml` file. Run the application using it as shown below: ```console curl -sSL https://raw.githubusercontent.com/bitnami/containers/main/bitnami/APP/docker-compose.yml > docker-compose.yml docker-compose up -d ``` > [!TIP] > Remember to replace the `APP` placeholder in the example command above with the correct value. ## Vulnerability scan in Bitnami container images As part of the release process, the Bitnami container images are analyzed for vulnerabilities. At this moment, we are using two different tools: - [Trivy](https://github.com/aquasecurity/trivy) - [Grype](https://github.com/anchore/grype) This scanning process is triggered via a GH action for every PR affecting the source code of the containers, regardless of its nature or origin. ## Retention policy Deprecated assets will be retained in the container registry ([Bitnami DockerHub org](https://hub.docker.com/u/bitnami)) without changes for, at least, 6 months after the deprecation. After that period, all the images will be moved to a new _"archived"_ repository. For instance, once deprecated an asset named _foo_ whose container repository was `bitnami/foo`, all the images will be moved to `bitnami/foo-archived` where they will remain indefinitely. Special images, like `bitnami/bitnami-shell` or `bitnami/sealed-secrets`, which are extensively used in Helm charts, will have an extended coexistence period of 1 year. ## Contributing We'd love for you to contribute to those container images. You can request new features by creating an [issue](https://github.com/bitnami/containers/issues/new/choose), or submit a [pull request](https://github.com/bitnami/containers/pulls) with your contribution. ## License Copyright © 2026 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --- ## File: bitnami/acmesolver/1.20/README.md # ⚠️ Important Notice: Upcoming changes to the Bitnami Catalog Beginning August 28th, 2025, Bitnami will evolve its public catalog to offer a curated set of hardened, security-focused images under the new [Bitnami Secure Images initiative](https://news.broadcom.com/app-dev/broadcom-introduces-bitnami-secure-images-for-production-ready-containerized-applications). As part of this transition: - Granting community users access for the first time to security-optimized versions of popular container images. - Bitnami will begin deprecating support for non-hardened, Debian-based software images in its free tier and will gradually remove non-latest tags from the public catalog. As a result, community users will have access to a reduced number of hardened images. These images are published only under the “latest” tag and are intended for development purposes - Starting August 28th, over two weeks, all existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be migrated from the public catalog (docker.io/bitnami) to the “Bitnami Legacy” repository (docker.io/bitnamilegacy), where they will no longer receive updates. - For production workloads and long-term support, users are encouraged to adopt Bitnami Secure Images, which include hardened containers, smaller attack surfaces, CVE transparency (via VEX/KEV), SBOMs, and enterprise support. These changes aim to improve the security posture of all Bitnami users by promoting best practices for software supply chain integrity and up-to-date deployments. For more details, visit the [Bitnami Secure Images announcement](https://github.com/bitnami/containers/issues/83267). --- ## File: bitnami/acmesolver/README.md # Bitnami Secure Image for ACME Solver > ACME Solver is a part of the cert-manager project. It will ensure certificates are valid and up to date periodically, and attempt to renew certificates at an appropriate time before expiry. > Cert-manager is a Kubernetes add-on to automate the management and issuance of TLS certificates from various issuing sources. [Overview of ACME Solver](https://github.com/jetstack/cert-manager) Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement. ## TL;DR ```console docker run --name redis -e ALLOW_EMPTY_PASSWORD=yes bitnami/acmesolver:latest ``` ## Before you begin Kubernetes cluster with `CustomResourceDefinition` or `ThirdPartyResource support` ## Why use Bitnami Secure Images? Those are hardened, minimal CVE images built and maintained by Bitnami. Bitnami Secure Images are based on the cloud-optimized, security-hardened enterprise [OS Photon Linux](https://vmware.github.io/photon/). Why choose BSI images? - Hardened secure images of popular open source software with Near-Zero Vulnerabilities - Vulnerability Triage & Prioritization with VEX Statements, KEV and EPSS Scores - Compliance focus with FIPS, STIG, and air-gap options, including secure bill of materials (SBOM) - Software supply chain provenance attestation through in-toto - First class support for the internet’s favorite Helm charts Each image comes with valuable security metadata. You can view the metadata in [our public catalog here](https://app-catalog.vmware.com/bitnami/apps). Note: Some data is only available with [commercial subscriptions to BSI](https://bitnami.com/). If you are looking for our previous generation of images based on Debian Linux, please see the [Bitnami Legacy registry](https://hub.docker.com/u/bitnamilegacy). ## Why use a non-root container? Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-work-with-non-root-containers-index.html). ## Supported tags and respective `Dockerfile` links Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html). ## Configuration The following section describes how to configure the application ### Further documentation For further documentation, please check [here](https://github.com/jetstack/cert-manager/blob/master/docs) ### FIPS configuration in Bitnami Secure Images The Bitnami ACME Solver Docker image from the [Bitnami Secure Images](https://go-vmware.broadcom.com/contact-us) catalog includes extra features and settings to configure the container with FIPS capabilities. You can configure the next environment variables: - `OPENSSL_FIPS`: whether OpenSSL runs in FIPS mode or not. `yes` (default), `no`. - `GODEBUG`: controls Go FIPS mode. Use `fips140=only` (restricted), `fips140=on` (relaxed), or `fips140=off` (disabled). ## Notable Changes ### Starting January 16, 2024 - The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes. ## License Copyright © 2026 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --- ## File: bitnami/activemq/README.md # Bitnami Secure Image for ActiveMQ > Apache ActiveMQ is an open source message broker written in Java together with a full Java Message Service (JMS) client. [Overview of ActiveMQ](https://activemq.apache.org/) Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement. ## TL;DR ```console docker run --name activemq bitnami/activemq:latest ``` ## Why use Bitnami Secure Images? Those are hardened, minimal CVE images built and maintained by Bitnami. Bitnami Secure Images are based on the cloud-optimized, security-hardened enterprise [OS Photon Linux](https://vmware.github.io/photon/). Why choose BSI images? - Hardened secure images of popular open source software with Near-Zero Vulnerabilities - Vulnerability Triage & Prioritization with VEX Statements, KEV and EPSS Scores - Compliance focus with FIPS, STIG, and air-gap options, including secure bill of materials (SBOM) - Software supply chain provenance attestation through in-toto - First class support for the internet’s favorite Helm charts Each image comes with valuable security metadata. You can view the metadata in [our public catalog here](https://app-catalog.vmware.com/bitnami/apps). Note: Some data is only available with [commercial subscriptions to BSI](https://bitnami.com/). If you are looking for our previous generation of images based on Debian Linux, please see the [Bitnami Legacy registry](https://hub.docker.com/u/bitnamilegacy). ## Supported tags and respective `Dockerfile` links Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html). ## Get this image The Bitnami ActiveMQ Docker image is only available to [Bitnami Secure Images](https://bitnami.com) customers. ## Why use a non-root container? Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-work-with-non-root-containers-index.html). ## Configuration The following section describes how to run commands ### Running commands To run commands inside this container, you can use `docker run`, for example to execute `activemq --help` you can follow the example below: ```console docker run --rm --name activemq bitnami/activemq:latest -- --help ``` Check the [official ActiveMQ documentation](https://activemq.apache.org/) for more information. ### Environment variables The following tables list the main variables you can set. #### Customizable environment variables | Name | Description | Default Value | |----------------------------------|-----------------------------------------------------------------------------------------------|-------------------------------| | `ACTIVEMQ_MOUNTED_CONF_DIR` | Directory for including custom configuration files (that override the default generated ones) | `${ACTIVEMQ_VOLUME_DIR}/conf` | | `ACTIVEMQ_MQTT_PORT_NUMBER` | ActiveMQ MQTT port number. | `1883` | | `ACTIVEMQ_AQMQ_PORT_NUMBER` | ActiveMQ AQMQ port number. | `5672` | | `ACTIVEMQ_HTTP_PORT_NUMBER` | ActiveMQ HTTP port number. | `8161` | | `ACTIVEMQ_STOMP_PORT_NUMBER` | ActiveMQ STOMP port number. | `61613` | | `ACTIVEMQ_WEBSOCKET_PORT_NUMBER` | ActiveMQ WebSocket port number. | `61614` | | `ACTIVEMQ_OPENWIRE_PORT_NUMBER` | ActiveMQ OpenWire port number. | `61616` | | `ACTIVEMQ_PASSWORD` | ActiveMQ password. | `nil` | | `ACTIVEMQ_SECRET` | ActiveMQ secret for encryption. | `nil` | #### Read-only environment variables | Name | Description | Value | |-----------------------------|------------------------------------------------------|-------------------------------------| | `ACTIVEMQ_BASE_DIR` | ActiveMQ installation directory. | `${BITNAMI_ROOT_DIR}/activemq` | | `ACTIVEMQ_BIN_DIR` | ActiveMQ directory for binary files. | `${ACTIVEMQ_BASE_DIR}/bin` | | `ACTIVEMQ_VOLUME_DIR` | Persistence base directory. | `${BITNAMI_VOLUME_DIR}/activemq` | | `ACTIVEMQ_DATA_DIR` | ActiveMQ configuration directory. | `${ACTIVEMQ_VOLUME_DIR}/data` | | `ACTIVEMQ_CONF_DIR` | ActiveMQ configuration directory. | `${ACTIVEMQ_BASE_DIR}/conf` | | `ACTIVEMQ_DEFAULT_CONF_DIR` | ActiveMQ default configuration directory. | `${ACTIVEMQ_BASE_DIR}/conf.default` | | `ACTIVEMQ_LOGS_DIR` | Directory where ActiveMQ logs are stored. | `${ACTIVEMQ_BASE_DIR}/logs` | | `ACTIVEMQ_TMP_DIR` | Directory where ActiveMQ temporary files are stored. | `${ACTIVEMQ_BASE_DIR}/tmp` | | `ACTIVEMQ_CONF_FILE` | ActiveMQ configuration file. | `${ACTIVEMQ_CONF_DIR}/activemq.xml` | | `ACTIVEMQ_LOG_FILE` | Path to the log file for ActiveMQ. | `${ACTIVEMQ_LOGS_DIR}/activemq.log` | | `ACTIVEMQ_PID_FILE` | Path to the PID file for ActiveMQ. | `${ACTIVEMQ_TMP_DIR}/activemq.pid` | | `ACTIVEMQ_HOME` | ActiveMQ home directory. | `$ACTIVEMQ_BASE_DIR` | | `ACTIVEMQ_DAEMON_USER` | ActiveMQ system user. | `activemq` | | `ACTIVEMQ_DAEMON_GROUP` | ActiveMQ system group. | `activemq` | | `JAVA_HOME` | Java installation folder. | `${BITNAMI_ROOT_DIR}/java` | | `ACTIVEMQ_PIDFILE` | ActiveMQ output destination | `${ACTIVEMQ_PID_FILE}` | | `ACTIVEMQ_OUT` | ActiveMQ output destination | `${ACTIVEMQ_LOG_FILE}` | ### FIPS configuration in Bitnami Secure Images The Bitnami ActiveMQ Docker image from the [Bitnami Secure Images](https://go-vmware.broadcom.com/contact-us) catalog includes extra features and settings to configure the container with FIPS capabilities. You can configure the next environment variables: - `OPENSSL_FIPS`: whether OpenSSL runs in FIPS mode or not. `yes` (default), `no`. - `JAVA_TOOL_OPTIONS`: controls Java FIPS mode. Use `-Djava.security.properties==/opt/bitnami/java/conf/security/java.security.restricted` (restricted), `-Djava.security.properties==/opt/bitnami/java/conf/security/java.security.relaxed` (relaxed), or `-Djava.security.properties==/opt/bitnami/java/conf/security/java.security.original` (off). ## License Copyright © 2026 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --- ## File: bitnami/airflow/README.md # Bitnami Secure Image for Apache Airflow > Apache Airflow is a tool to express and execute workflows as directed acyclic graphs (DAGs). It includes utilities to schedule tasks, monitor task progress and handle task dependencies. [Overview of Apache Airflow](https://airflow.apache.org/) Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement. ## TL;DR ```console docker run --name airflow bitnami/airflow:latest ``` ## Using `docker-compose.yml` The docker-compose.yaml file of this container can be found in the [Bitnami Containers repository](https://github.com/bitnami/containers/). [https://github.com/bitnami/containers/tree/main/bitnami/airflow/docker-compose.yml](https://github.com/bitnami/containers/tree/main/bitnami/airflow/docker-compose.yml) Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/airflow). ## Why use Bitnami Secure Images? Those are hardened, minimal CVE images built and maintained by Bitnami. Bitnami Secure Images are based on the cloud-optimized, security-hardened enterprise [OS Photon Linux](https://vmware.github.io/photon/). Why choose BSI images? - Hardened secure images of popular open source software with Near-Zero Vulnerabilities - Vulnerability Triage & Prioritization with VEX Statements, KEV and EPSS Scores - Compliance focus with FIPS, STIG, and air-gap options, including secure bill of materials (SBOM) - Software supply chain provenance attestation through in-toto - First class support for the internet’s favorite Helm charts Each image comes with valuable security metadata. You can view the metadata in [our public catalog here](https://app-catalog.vmware.com/bitnami/apps). Note: Some data is only available with [commercial subscriptions to BSI](https://bitnami.com/). If you are looking for our previous generation of images based on Debian Linux, please see the [Bitnami Legacy registry](https://hub.docker.com/u/bitnamilegacy). ## Supported tags and respective `Dockerfile` links Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html). ## How to use this image Airflow requires access to a PostgreSQL database to store information. We will use the [Bitnami PostgreSQL image](https://github.com/bitnami/containers/tree/main/bitnami/postgresql) for the database requirements. Additionally, if you pretend to use the `CeleryExecutor`, you will also need a [Bitnami Redis(R) server](https://github.com/bitnami/containers/tree/main/bitnami/redis). ### Persisting your application The Bitnami Airflow container relies on the PostgreSQL database & Redis to persist the data. This means that Airflow does not persist anything. To avoid loss of data, you should mount volumes for persistence of [PostgreSQL data](https://github.com/bitnami/containers/blob/main/bitnami/mariadb#persisting-your-database) and [Redis(R) data](https://github.com/bitnami/containers/blob/main/bitnami/redis#persisting-your-database) The above examples define docker volumes namely `postgresql_data`, and `redis_data`. The Airflow application state will persist as long as these volumes are not removed. To avoid inadvertent removal of these volumes you can [mount host directories as data volumes](https://docs.docker.com/engine/tutorials/dockervolumes/). Alternatively you can make use of volume plugins to host the volume data. ## Configuration The following sections describe how to load DAGs, install modules, and set environment variables. ### Load DAG files Custom DAG files can be mounted to `/opt/bitnami/airflow/dags`. ### Installing additional python modules This container supports the installation of additional python modules at start-up time. In order to do that, you can mount a `requirements.txt` file with your specific needs under the path `/bitnami/python/requirements.txt`. ### Environment variables The following tables list the main variables you can set. #### Customizable environment variables | Name | Description | Default Value | |------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------| | `AIRFLOW_USERNAME` | Airflow username | `user` | | `ALLOW_EMPTY_PASSWORD` | Allow an empty password. | `no` | | `AIRFLOW_PASSWORD` | Airflow password | `nil` | | `AIRFLOW_FIRSTNAME` | Airflow firstname | `Firstname` | | `AIRFLOW_LASTNAME` | Airflow lastname | `Lastname` | | `AIRFLOW_EMAIL` | Airflow email | `user@example.com` | | `AIRFLOW_COMPONENT_TYPE` | Airflow component type. Allowed values: *api-server*, *scheduler*, *dag-processor*, *triggerer*, *webserver* (2.x versions only), *worker*. | `api-server` | | `AIRFLOW_EXECUTOR` | Airflow executor. | `LocalExecutor` | | `AIRFLOW_RAW_FERNET_KEY` | Airflow raw/unencoded Fernet key | `nil` | | `AIRFLOW_FORCE_OVERWRITE_CONF_FILE` | Force the airflow.cfg config file generation. | `no` | | `AIRFLOW_FERNET_KEY` | Airflow Fernet key | `nil` | | `AIRFLOW_WEBSERVER_SECRET_KEY` | Airflow webserver secret key | `nil` | | `AIRFLOW_APISERVER_SECRET_KEY` | Airflow API secret key | `nil` | | `AIRFLOW_APISERVER_BASE_URL` | Airflow API server base URL. | `nil` | | `AIRFLOW_APISERVER_HOST` | Airflow API server host | `127.0.0.1` | | `AIRFLOW_APISERVER_PORT_NUMBER` | Airflow API server port. | `8080` | | `AIRFLOW_LOAD_EXAMPLES` | To load example tasks into the application. | `yes` | | `AIRFLOW_HOSTNAME_CALLABLE` | Method to obtain the hostname. | `nil` | | `AIRFLOW_POOL_NAME` | Pool name. | `nil` | | `AIRFLOW_POOL_SIZE` | Pool size, required with AIRFLOW_POOL_NAME. | `nil` | | `AIRFLOW_POOL_DESC` | Pool description, required with AIRFLOW_POOL_NAME. | `nil` | | `AIRFLOW_STANDALONE_DAG_PROCESSOR` | Enable running Dag Processor in standalone mode | `no` | | `AIRFLOW_TRIGGERER_DEFAULT_CAPACITY` | How many triggers a single Triggerer can run at once. | `1000` | | `AIRFLOW_WORKER_QUEUE` | A queue for the worker to pull tasks from. | `nil` | | `AIRFLOW_SKIP_DB_SETUP` | Skip db init / db migrate actions during the setup | `no` | | `PYTHONPYCACHEPREFIX` | Configure Python .pyc files cache prefix | `/opt/bitnami/airflow/venv/tmp` | | `AIRFLOW_DB_MIGRATE_TIMEOUT` | How much time to wait for database migrations | `120` | | `AIRFLOW_ENABLE_HTTPS` | Whether to enable HTTPS for Airflow by default. | `no` | | `AIRFLOW_EXTERNAL_APISERVER_PORT_NUMBER` | External HTTP/HTTPS port for Airflow. | `80` | | `AIRFLOW_DATABASE_HOST` | Hostname for PostgreSQL server. | `postgresql` | | `AIRFLOW_DATABASE_PORT_NUMBER` | Port used by PostgreSQL server. | `5432` | | `AIRFLOW_DATABASE_NAME` | Database name that Airflow will use to connect with the database. | `bitnami_airflow` | | `AIRFLOW_DATABASE_USERNAME` | Database user that Airflow will use to connect with the database. | `bn_airflow` | | `AIRFLOW_DATABASE_PASSWORD` | Database password that Airflow will use to connect with the database. | `nil` | | `AIRFLOW_DATABASE_USE_SSL` | Set to yes if the database is using SSL. | `no` | | `AIRFLOW_REDIS_USE_SSL` | Set to yes if Redis(R) uses SSL. | `no` | | `REDIS_HOST` | Hostname for Redis(R) server. | `redis` | | `REDIS_PORT_NUMBER` | Port used by Redis(R) server. | `6379` | | `REDIS_USER` | User that Airflow will use to connect with Redis(R). | `nil` | | `REDIS_PASSWORD` | Password that Airflow will use to connect with Redis(R). | `nil` | | `REDIS_DATABASE` | Name of the Redis(R) database. | `1` | | `AIRFLOW_LDAP_ENABLE` | Enable LDAP authentication. | `no` | | `AIRFLOW_LDAP_URI` | LDAP server URI. | `nil` | | `AIRFLOW_LDAP_SEARCH` | LDAP search base. | `nil` | | `AIRFLOW_LDAP_UID_FIELD` | LDAP field used for uid. | `nil` | | `AIRFLOW_LDAP_BIND_USER` | LDAP user name. | `nil` | | `AIRFLOW_LDAP_BIND_PASSWORD` | LDAP user password. | `nil` | | `AIRFLOW_LDAP_USER_REGISTRATION` | User self registration. | `True` | | `AIRFLOW_LDAP_USER_REGISTRATION_ROLE` | Role name to be assign when a user registers himself. | `nil` | | `AIRFLOW_LDAP_ROLES_MAPPING` | Mapping from LDAP DN to a list of Airflow roles. | `nil` | | `AIRFLOW_LDAP_ROLES_SYNC_AT_LOGIN` | Replace ALL the user roles each login, or only on registration. | `True` | | `AIRFLOW_LDAP_USE_TLS` | Use LDAP SSL. | `False` | | `AIRFLOW_LDAP_ALLOW_SELF_SIGNED` | Allow self signed certificates in LDAP ssl. | `False` | | `AIRFLOW_LDAP_TLS_CA_CERTIFICATE` | File that store the CA for LDAP ssl. | `nil` | #### Read-only environment variables | Name | Description | Value | |-------------------------------|-------------------------------------------|-------------------------------------------| | `AIRFLOW_BASE_DIR` | Airflow home/installation directory. | `${BITNAMI_ROOT_DIR}/airflow` | | `AIRFLOW_BIN_DIR` | Airflow directory for binary executables. | `${AIRFLOW_BASE_DIR}/venv/bin` | | `AIRFLOW_LOGS_DIR` | Airflow logs directory. | `${AIRFLOW_BASE_DIR}/logs` | | `AIRFLOW_SCHEDULER_LOGS_DIR` | Airflow scheduler logs directory. | `${AIRFLOW_LOGS_DIR}/scheduler` | | `AIRFLOW_CONF_FILE` | Airflow configuration file. | `${AIRFLOW_BASE_DIR}/airflow.cfg` | | `AIRFLOW_WEBSERVER_CONF_FILE` | Airflow Webserver configuration file. | `${AIRFLOW_BASE_DIR}/webserver_config.py` | | `AIRFLOW_TMP_DIR` | Airflow directory temporary files. | `${AIRFLOW_BASE_DIR}/tmp` | | `AIRFLOW_DAGS_DIR` | Airflow data to be persisted. | `${AIRFLOW_BASE_DIR}/dags` | | `AIRFLOW_DAEMON_USER` | Airflow system user. | `airflow` | | `AIRFLOW_DAEMON_GROUP` | Airflow system group. | `airflow` | > In addition to the previous environment variables, all the parameters from the configuration file can be overwritten by using environment variables with this format: `AIRFLOW__{SECTION}__{KEY}`. Note the double underscores. #### SMTP Configuration To configure Airflow to send email using SMTP you can set the following environment variables: - `AIRFLOW__SMTP__SMTP_HOST`: Host for outgoing SMTP email. Default: **localhost** - `AIRFLOW__SMTP__SMTP_PORT`: Port for outgoing SMTP email. Default: **25** - `AIRFLOW__SMTP__SMTP_STARTTLS`: To use TLS communication. Default: **True** - `AIRFLOW__SMTP__SMTP_SSL`: To use SSL communication. Default: **False** - `AIRFLOW__SMTP__SMTP_USER`: User of SMTP used for authentication (likely email). No defaults. - `AIRFLOW__SMTP__SMTP_PASSWORD`: Password for SMTP. No defaults. - `AIRFLOW__SMTP__SMTP_MAIL_FROM`: To modify the "from email address". Default: **** ### FIPS configuration in Bitnami Secure Images The Bitnami Apache Airflow Docker image from the [Bitnami Secure Images](https://go-vmware.broadcom.com/contact-us) catalog includes extra features and settings to configure the container with FIPS capabilities. You can configure the next environment variables: - `OPENSSL_FIPS`: whether OpenSSL runs in FIPS mode or not. `yes` (default), `no`. ## Notable changes The following subsections describe notable changes. ### Starting October 30, 2024 - The Airflow container now supports running as a Web server, Scheduler or Worker component, so it's no longer necessary to combine this container image with `bitnami/airflow-scheduler` and `bitnami/airflow-worker` in order to use the `CeleryExecutor`. - The `AIRFLOW_COMPONENT_TYPE` environment variable was introduced to specify the component type. Current supported values are `webserver`, `scheduler` and `worker`, although it's planned to add soon support for `dag-processor` and `triggerer` components. The default value is `webserver`. ### 1.10.15-debian-10-r17 and 2.0.1-debian-10-r50 - The size of the container image has been decreased. - The configuration logic is now based on Bash scripts in the *rootfs/* folder. ## License Copyright © 2026 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --- ## File: bitnami/alertmanager/README.md # Bitnami Secure Image for AlertManager > The Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integrations. [Overview of AlertManager](https://github.com/prometheus/alertmanager) Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement. ## TL;DR ```console docker run --name alertmanager bitnami/alertmanager:latest ``` ## Why use Bitnami Secure Images? Those are hardened, minimal CVE images built and maintained by Bitnami. Bitnami Secure Images are based on the cloud-optimized, security-hardened enterprise [OS Photon Linux](https://vmware.github.io/photon/). Why choose BSI images? - Hardened secure images of popular open source software with Near-Zero Vulnerabilities - Vulnerability Triage & Prioritization with VEX Statements, KEV and EPSS Scores - Compliance focus with FIPS, STIG, and air-gap options, including secure bill of materials (SBOM) - Software supply chain provenance attestation through in-toto - First class support for the internet’s favorite Helm charts Each image comes with valuable security metadata. You can view the metadata in [our public catalog here](https://app-catalog.vmware.com/bitnami/apps). Note: Some data is only available with [commercial subscriptions to BSI](https://bitnami.com/). If you are looking for our previous generation of images based on Debian Linux, please see the [Bitnami Legacy registry](https://hub.docker.com/u/bitnamilegacy). ## Why use a non-root container? Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-work-with-non-root-containers-index.html). ## Supported tags and respective `Dockerfile` links Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html). ## Get this image The Bitnami AlertManager Docker image is only available to [Bitnami Secure Images](https://bitnami.com) customers. ## Persisting your application If you remove the container all your data and configurations will be lost, and the next time you run the image the database will be reinitialized. To avoid this loss of data, you should mount a volume that will persist even after the container is removed. For persistence you should mount a volume at the `/opt/bitnami/alertmanager/data` path. The above examples define a docker volume namely `alertmanager_data`. The Alertmanager application state will persist as long as this volume is not removed. To avoid inadvertent removal of this volume you can [mount host directories as data volumes](https://docs.docker.com/engine/tutorials/dockervolumes/). Alternatively you can make use of volume plugins to host the volume data. ```console docker run -v /path/to/alertmanager-persistence:/opt/bitnami/alertmanager/data bitnami/alertmanager:latest ``` > **NOTE** As this is a non-root container, the mounted files and directories must have the proper permissions for the UID `1001`. ## Connecting to other containers Using [Docker container networking](https://docs.docker.com/engine/userguide/networking/), a different server running inside a container can easily be accessed by your application containers and vice-versa. Containers attached to the same network can communicate with each other using the container name as the hostname. ### Using the Command Line #### Step 1: Create a network ```console docker network create alertmanager-network --driver bridge ``` #### Step 2: Launch the Alertmanager container within your network Use the `--network ` argument to the `docker run` command to attach the container to the `alertmanager-network` network. ```console docker run --name alertmanager-node1 --network alertmanager-network bitnami/alertmanager:latest ``` #### Step 3: Run another containers We can launch another containers using the same flag (`--network NETWORK`) in the `docker run` command. If you also set a name to your container, you will be able to use it as hostname in your network. ## Configuration The configuration can easily be setup by mounting your own configuration file on the directory `/opt/bitnami/alertmanager/conf/`: ```console docker run --name alertmanager -v /path/to/config.yml:/opt/bitnami/alertmanager/conf/config.yml bitnami/alertmanager:latest ``` After that, your configuration will be taken into account in the server's behaviour. Using Docker Compose: ```yaml version: '2' services: alertmanager: image: bitnami/alertmanager:latest volumes: - /path/to/config.yml:/opt/bitnami/alertmanager/conf/config.yml ``` Configuration is yaml based. The full documentation of the configuration can be found [here](https://prometheus.io/docs/alerting/configuration/). ### Amtool `amtool` is a cli tool for interacting with the alertmanager api. It is bundled with all releases of alertmanager. ### FIPS configuration in Bitnami Secure Images The Bitnami AlertManager Docker image from the [Bitnami Secure Images](https://go-vmware.broadcom.com/contact-us) catalog includes extra features and settings to configure the container with FIPS capabilities. You can configure the next environment variables: - `OPENSSL_FIPS`: whether OpenSSL runs in FIPS mode or not. `yes` (default), `no`. - `GODEBUG`: controls Go FIPS mode. Use `fips140=only` (restricted), `fips140=on` (relaxed), or `fips140=off` (disabled). ## Logging The Bitnami AlertManager Docker image sends the container logs to the `stdout`. You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver. ## Notable Changes ### Starting January 16, 2024 - The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes. ## License Copyright © 2026 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --- ## File: bitnami/apache/README.md # Bitnami Secure Image for Apache > Apache HTTP Server is an open-source HTTP server. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards. [Overview of Apache](https://httpd.apache.org/) Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement. ## TL;DR ```console docker run --name apache bitnami/apache:latest ``` ## Using `docker-compose.yml` The docker-compose.yaml file of this container can be found in the [Bitnami Containers repository](https://github.com/bitnami/containers/). [https://github.com/bitnami/containers/tree/main/bitnami/apache/docker-compose.yml](https://github.com/bitnami/containers/tree/main/bitnami/apache/docker-compose.yml) Please be aware this file has not undergone internal testing. Consequently, we advise its use exclusively for development or testing purposes. For production-ready deployments, we highly recommend utilizing its associated [Bitnami Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/apache). ## Why use Bitnami Secure Images? Those are hardened, minimal CVE images built and maintained by Bitnami. Bitnami Secure Images are based on the cloud-optimized, security-hardened enterprise [OS Photon Linux](https://vmware.github.io/photon/). Why choose BSI images? - Hardened secure images of popular open source software with Near-Zero Vulnerabilities - Vulnerability Triage & Prioritization with VEX Statements, KEV and EPSS Scores - Compliance focus with FIPS, STIG, and air-gap options, including secure bill of materials (SBOM) - Software supply chain provenance attestation through in-toto - First class support for the internet’s favorite Helm charts Each image comes with valuable security metadata. You can view the metadata in [our public catalog here](https://app-catalog.vmware.com/bitnami/apps). Note: Some data is only available with [commercial subscriptions to BSI](https://bitnami.com/). If you are looking for our previous generation of images based on Debian Linux, please see the [Bitnami Legacy registry](https://hub.docker.com/u/bitnamilegacy). ## How to deploy Apache in Kubernetes? Deploying Bitnami applications as Helm Charts is the easiest way to get started with our applications on Kubernetes. Read more about the installation in the [Bitnami Apache Chart GitHub repository](https://github.com/bitnami/charts/tree/master/bitnami/apache). ## Why use a non-root container? Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-work-with-non-root-containers-index.html). ## Supported tags and respective `Dockerfile` links Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html). ## Get this image The Bitnami Apache Docker image is only available to [Bitnami Secure Images](https://bitnami.com) customers. ## Hosting a static website The `/app` path is configured as the Apache [DocumentRoot](https://httpd.apache.org/docs/2.4/urlmapping.html#documentroot). Content mounted here is served by the default catch-all virtual host. ```console docker run --name apache -v /path/to/app:/app bitnami/apache:latest ``` or using Docker Compose: ```yaml version: '2' services: apache: image: bitnami/apache:latest ports: - 80:8080 - 443:8443 volumes: - /path/to/app:/app ``` > **NOTE** As this is a non-root container, the mounted files and directories must have the proper permissions for the UID `1001`. ## Accessing your server from the host To access your web server from your host machine you can ask Docker to map a random port on your host to ports `8080` and `8443` exposed in the container. ```console docker run --name apache -P bitnami/apache:latest ``` Run `docker port` to determine the random ports Docker assigned. ```console $ docker port apache 8443/tcp -> 0.0.0.0:32768 8080/tcp -> 0.0.0.0:32769 ``` You can also manually specify the ports you want forwarded from your host to the container. ```console docker run -p 8080:8080 -p 8443:8443 bitnami/apache:latest ``` Access your web server in the browser by navigating to `http://localhost:8080/`. ## Configuration The following section describes the supported environment variables ### Environment variables The following tables list the main variables you can set. #### Customizable environment variables | Name | Description | Default Value | |----------------------------|-----------------------------------|---------------| | `APACHE_HTTP_PORT_NUMBER` | HTTP port number used by Apache. | `nil` | | `APACHE_HTTPS_PORT_NUMBER` | HTTPS port number used by Apache. | `nil` | | `APACHE_SERVER_TOKENS` | Apache ServerTokens directive. | `Prod` | #### Read-only environment variables | Name | Description | Value | |------------------------------------|-----------------------------------------------------------|-----------------------------------| | `WEB_SERVER_TYPE` | Web server type | `apache` | | `APACHE_BASE_DIR` | Apache installation directory. | `${BITNAMI_ROOT_DIR}/apache` | | `APACHE_BIN_DIR` | Apache directory for binary executables. | `${APACHE_BASE_DIR}/bin` | | `APACHE_CONF_DIR` | Apache configuration directory. | `${APACHE_BASE_DIR}/conf` | | `APACHE_DEFAULT_CONF_DIR` | Apache default configuration directory. | `${APACHE_BASE_DIR}/conf.default` | | `APACHE_HTDOCS_DIR` | Directory containing HTTP files to serve via Apache. | `${APACHE_BASE_DIR}/htdocs` | | `APACHE_TMP_DIR` | Apache directory for runtime temporary files. | `${APACHE_BASE_DIR}/var/run` | | `APACHE_LOGS_DIR` | Apache directory for logs. | `${APACHE_BASE_DIR}/logs` | | `APACHE_VHOSTS_DIR` | Apache directory for virtual hosts. | `${APACHE_CONF_DIR}/vhosts` | | `APACHE_HTACCESS_DIR` | Apache directory for htaccess files. | `${APACHE_VHOSTS_DIR}/htaccess` | | `APACHE_CONF_FILE` | Path to the Apache configuration. | `${APACHE_CONF_DIR}/httpd.conf` | | `APACHE_PID_FILE` | Path to the Apache PID file. | `${APACHE_TMP_DIR}/httpd.pid` | | `APACHE_DAEMON_USER` | Apache system user. | `daemon` | | `APACHE_DAEMON_GROUP` | Apache system group. | `daemon` | | `APACHE_DEFAULT_HTTP_PORT_NUMBER` | Default Apache HTTP port number to enable at build time. | `8080` | | `APACHE_DEFAULT_HTTPS_PORT_NUMBER` | Default Apache HTTPS port number to enable at build time. | `8443` | ### Adding custom virtual hosts The default `httpd.conf` includes virtual hosts placed in `/opt/bitnami/apache/conf/vhosts/`. You can mount a `my_vhost.conf` file containing your custom virtual hosts at the `/vhosts` folder. For example, in order add a vhost for `www.example.com`: #### Step 1: Write your `my_vhost.conf` file with the following content ```apache ServerName www.example.com DocumentRoot "/app" Options Indexes FollowSymLinks AllowOverride All Require all granted ``` #### Step 2: Mount the configuration as a volume ```console docker run --name apache \ -v /path/to/my_vhost.conf:/vhosts/my_vhost.conf:ro \ bitnami/apache:latest ``` or using Docker Compose: ```yaml version: '2' services: apache: image: bitnami/apache:latest ports: - 80:8080 - 443:8443 volumes: - /path/to/my_vhost.conf:/vhosts/my_vhost.conf:ro ``` ### Using custom SSL certificates *NOTE:* The steps below assume that you are using a custom domain name and that you have already configured the custom domain name to point to your server. This container comes with SSL support already pre-configured and with a dummy certificate in place (`tls.crt` and `tls.key` files in `/certs`). If you want to use your own certificate (`.crt`) and certificate key (`.key`) files, follow the steps below: #### Step 1: Prepare your certificate files In your local computer, create a folder called `certs` and put your certificates files. Make sure you rename both files to `server.crt` and `server.key` respectively: ```console mkdir /path/to/apache-certs -p cp /path/to/certfile.crt /path/to/apache-certs/server.crt cp /path/to/keyfile.key /path/to/apache-certs/server.key ``` #### Step 2: Run the Apache image Run the Apache image, mounting the certificates directory from your host. ```console docker run --name apache \ -v /path/to/apache-certs:/certs \ bitnami/apache:latest ``` or using Docker Compose: ```yaml version: '2' services: apache: image: bitnami/apache:latest ports: - 80:8080 - 443:8443 volumes: - /path/to/apache-certs:/certs ``` ### Full configuration The image looks for configurations in `/opt/bitnami/apache/conf`. You can overwrite the `httpd.conf` file using your own custom configuration file. ```console docker run --name apache \ -v /path/to/httpd.conf:/opt/bitnami/apache/conf/httpd.conf \ bitnami/apache:latest ``` or using Docker Compose: ```yaml version: '2' services: apache: image: bitnami/apache:latest ports: - 80:8080 - 443:8443 volumes: - /path/to/httpd.conf:/opt/bitnami/apache/conf/httpd.conf ``` ### FIPS configuration in Bitnami Secure Images The Bitnami Apache Docker image from the [Bitnami Secure Images](https://go-vmware.broadcom.com/contact-us) catalog includes extra features and settings to configure the container with FIPS capabilities. You can configure the next environment variables: - `OPENSSL_FIPS`: whether OpenSSL runs in FIPS mode or not. `yes` (default), `no`. ## Reverse proxy to other containers Apache can be used to reverse proxy to other containers using Docker's linking system. This is particularly useful if you want to serve dynamic content through an Apache frontend. **Further Reading:** - [mod_proxy documentation](http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#forwardreverse) ## Logging The Bitnami Apache Docker image sends the container logs to the `stdout`. You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver. ## Customize this image The Bitnami Apache Docker image is designed to be extended so it can be used as the base image for your custom web applications. ### Extend this image Before extending this image, please note there are certain configuration settings you can modify using the original image: - Settings that can be adapted using environment variables. For instance, you can change the ports used by Apache for HTTP and HTTPS, by setting the environment variables `APACHE_HTTP_PORT_NUMBER` and `APACHE_HTTPS_PORT_NUMBER` respectively. - [Adding custom virtual hosts](#adding-custom-virtual-hosts). - [Replacing the 'httpd.conf' file](#full-configuration). - [Using custom SSL certificates](#using-custom-ssl-certificates). If your desired customizations cannot be covered using the methods mentioned above, extend the image. To do so, create your own image using a Dockerfile with the format below: ```Dockerfile FROM bitnami/apache ### Put your customizations below ... ``` Here is an example of extending the image with the following modifications: - Install the `vim` editor - Modify the Apache configuration file - Modify the ports used by Apache - Change the user that runs the container ```Dockerfile FROM bitnami/apache ### Change user to perform privileged actions USER 0 ### Install 'vim' RUN install_packages vim ### Revert to the original non-root user USER 1001 ### Enable mod_ratelimit module RUN sed -i -r 's/#LoadModule ratelimit_module/LoadModule ratelimit_module/' /opt/bitnami/apache/conf/httpd.conf ### Modify the ports used by Apache by default ## It is also possible to change these environment variables at runtime ENV APACHE_HTTP_PORT_NUMBER=8181 EXPOSE 8181 8443 ### Modify the default container user USER 1002 ``` Based on the extended image, you can use a Docker Compose file like the one below to add other features: - Add a custom virtual host - Add custom certificates - Clone your web application and serve it through Apache ```yaml version: '2' services: apache: build: . ports: - 80:8181 - 443:8443 depends_on: - cloner volumes: - ./config/my_vhost.conf:/vhosts/my_vhost.conf:ro - ./certs:/certs - data:/app cloner: image: bitnami/git:latest command: - clone - https://github.com/cloudacademy/static-website-example - /app volumes: - data:/app volumes: data: driver: local ``` ## Useful Links - [Create An AMP Development Environment With Bitnami Containers](https://docs.bitnami.com/containers/how-to/create-amp-environment-containers/) ## Notable Changes ### 2.4.64-debian-12-r2 - This image updates TLS-related files: certificates and keys are now `tls.crt`/`tls.key` (from `server.crt`/`server.key`), and the certificate signing request is now `tls.csr` (from `server.csr`). This change aligns better with the kubernetes.io/tls secret type, enhancing consistency. ### 2.4.54-debian-11-r22 - Removed the [Apache PageSpeed Module (`mod_pagespeed`)](https://developers.google.com/speed/pagespeed/module). ### 2.4.43-debian-10-r66 - Included [Apache PageSpeed Module (`mod_pagespeed`)](https://developers.google.com/speed/pagespeed/module). It is disabled by default. To enable it, uncomment the following lines in `httpd.conf`: ```config ##Include conf/pagespeed.conf ##Include conf/pagespeed_libraries.conf ``` - Included [ModSecurity v2](https://github.com/SpiderLabs/ModSecurity). It is disabled by default. To enable it, mount and enable your custom ModSecurity rules for the virtual hosts, and uncomment the following line in `httpd.conf`: ```config ##LoadModule security2_module modules/mod_security2.so ``` - Included [ModSecurity v3](https://github.com/SpiderLabs/ModSecurity) and [ModSecurity v3 Apache Connector (`mod_security3`)](https://github.com/SpiderLabs/ModSecurity-apache). It is disabled by default. To enable it, mount and enable your custom ModSecurity rules for the virtual hosts, and uncomment the following line in `httpd.conf`: ```config ##LoadModule security3_module modules/mod_security3.so ``` ### 2.4.41-debian-9-r40 and 2.4.41-ol-7-r42 - Decrease the size of the container. The configuration logic is now based on Bash scripts in the `rootfs/` folder. ### 2.4.39-debian-9-r40 and 2.4.39-ol-7-r50 - This image has been adapted so it's easier to customize. See the [Customize this image](#customize-this-image) section for more information. - The Apache configuration volume (`/bitnami/apache`) has been deprecated, and support for this feature will be dropped in the near future. Until then, the container will enable the Apache configuration from that volume if it exists. By default, and if the configuration volume does not exist, the configuration files will be regenerated each time the container is created. Users wanting to apply custom Apache configuration files are advised to mount a volume for the configuration at `/opt/bitnami/apache/conf`, or mount specific configuration files individually. - Enabling custom Apache certificates by placing them at `/opt/bitnami/apache/certs` has been deprecated, and support for this functionality will be dropped in the near future. Users wanting to enable custom certificates are advised to mount their certificate files on top of the preconfigured ones at `/certs`. Find an example at [Using custom SSL certificates](#using-custom-ssl-certificates). ### 2.4.34-r8 - The Apache container has been migrated to a non-root user approach. Previously the container ran as the `root` user and the Apache daemon was started as the `apache` user. From now on, both the container and the Apache daemon run as user `1001`. As a consequence, the HTTP/HTTPS ports exposed by the container are now 8080/8443 instead of 80/443. You can revert this behavior by changing `USER 1001` to `USER root` in the Dockerfile. ### 2.4.18-r0 - The configuration volume has been moved to `/bitnami/apache`. Now you only need to mount a single volume at `/bitnami/apache` for persisting configuration. `/app` is still used for serving content by the default virtual host. - The logs are always sent to the `stdout` and are no longer collected in the volume. ### 2.4.12-4-r01 - The `/app` directory is no longer exported as a volume. This caused problems when building on top of the image, since changes in the volume are not persisted between Dockerfile `RUN` instructions. To keep the previous behavior (so that you can mount the volume in another container), create the container with the `-v /app` option. ## License Copyright © 2026 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --- ## File: bitnami/apache-exporter/README.md # Bitnami Secure Image for Apache Exporter > Apache Exporter gathers statistics from the mod_status Apache module via HTTP for Prometheus consumption. [Overview of Apache Exporter](https://github.com/Lusitaniae/apache_exporter) Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement. ## TL;DR ```console docker run --name apache-exporter bitnami/apache-exporter:latest ``` ## Why use Bitnami Secure Images? Those are hardened, minimal CVE images built and maintained by Bitnami. Bitnami Secure Images are based on the cloud-optimized, security-hardened enterprise [OS Photon Linux](https://vmware.github.io/photon/). Why choose BSI images? - Hardened secure images of popular open source software with Near-Zero Vulnerabilities - Vulnerability Triage & Prioritization with VEX Statements, KEV and EPSS Scores - Compliance focus with FIPS, STIG, and air-gap options, including secure bill of materials (SBOM) - Software supply chain provenance attestation through in-toto - First class support for the internet’s favorite Helm charts Each image comes with valuable security metadata. You can view the metadata in [our public catalog here](https://app-catalog.vmware.com/bitnami/apps). Note: Some data is only available with [commercial subscriptions to BSI](https://bitnami.com/). If you are looking for our previous generation of images based on Debian Linux, please see the [Bitnami Legacy registry](https://hub.docker.com/u/bitnamilegacy). ## Why use a non-root container? Non-root container images add an extra layer of security and are generally recommended for production environments. However, because they run as a non-root user, privileged tasks are typically off-limits. Learn more about non-root containers [in our docs](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-work-with-non-root-containers-index.html). ## Supported tags and respective `Dockerfile` links Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html). ## Get this image The Bitnami Apache Exporter Docker image is only available to [Bitnami Secure Images](https://bitnami.com) customers. ## Connecting to other containers Using [Docker container networking](https://docs.docker.com/engine/userguide/networking/), a different server running inside a container can easily be accessed by your application containers and vice-versa. Containers attached to the same network can communicate with each other using the container name as the hostname. ### Using the Command Line #### Step 1: Create a network ```console docker network create apache-exporter-network --driver bridge ``` #### Step 2: Launch the apache-exporter container within your network Use the `--network ` argument to the `docker run` command to attach the container to the `apache-exporter-network` network. ```console docker run --name apache-exporter-node1 --network apache-exporter-network bitnami/apache-exporter:latest ``` #### Step 3: Run another containers We can launch another containers using the same flag (`--network NETWORK`) in the `docker run` command. If you also set a name to your container, you will be able to use it as hostname in your network. ## Configuration Find all the configuration flags in [the Apache Exporter official documentation](https://github.com/Lusitaniae/apache_exporter#readme). ### FIPS configuration in Bitnami Secure Images The Bitnami Apache Exporter Docker image from the [Bitnami Secure Images](https://go-vmware.broadcom.com/contact-us) catalog includes extra features and settings to configure the container with FIPS capabilities. You can configure the next environment variables: - `OPENSSL_FIPS`: whether OpenSSL runs in FIPS mode or not. `yes` (default), `no`. ## Logging The Bitnami Apache Exporter Docker image sends the container logs to the `stdout`. You can configure the containers [logging driver](https://docs.docker.com/engine/admin/logging/overview/) using the `--log-driver` option if you wish to consume the container logs differently. In the default configuration docker uses the `json-file` driver. ## Notable Changes ### Starting January 16, 2024 - The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes. ## License Copyright © 2026 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --- ## File: bitnami/apisix/README.md # Bitnami Secure Image for Apache APISIX > Apache APISIX is high-performance, real-time API Gateway. Features load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, amongst others. [Overview of Apache APISIX](https://apisix.apache.org/) Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement. ## TL;DR ```console docker run -it --name apisix bitnami/apisix:latest ``` ## Why use Bitnami Secure Images? Those are hardened, minimal CVE images built and maintained by Bitnami. Bitnami Secure Images are based on the cloud-optimized, security-hardened enterprise [OS Photon Linux](https://vmware.github.io/photon/). Why choose BSI images? - Hardened secure images of popular open source software with Near-Zero Vulnerabilities - Vulnerability Triage & Prioritization with VEX Statements, KEV and EPSS Scores - Compliance focus with FIPS, STIG, and air-gap options, including secure bill of materials (SBOM) - Software supply chain provenance attestation through in-toto - First class support for the internet’s favorite Helm charts Each image comes with valuable security metadata. You can view the metadata in [our public catalog here](https://app-catalog.vmware.com/bitnami/apps). Note: Some data is only available with [commercial subscriptions to BSI](https://bitnami.com/). If you are looking for our previous generation of images based on Debian Linux, please see the [Bitnami Legacy registry](https://hub.docker.com/u/bitnamilegacy). ## Supported tags and respective `Dockerfile` links Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html). ## Get this image The Bitnami Apache APISIX Docker image is only available to [Bitnami Secure Images](https://bitnami.com) customers. ## Configuration The following section describes how to run commands ### Running commands To run commands inside this container you can use `docker run`, for example to execute `apisix --help` you can follow the example below: ```console docker run --rm --name apisix bitnami/apisix:latest --help ``` Check the [official Apache APISIX documentation](https://apisix.apache.org/docs/) for more information about how to use Apache APISIX. ### FIPS configuration in Bitnami Secure Images The Bitnami Apache APISIX Docker image from the [Bitnami Secure Images](https://go-vmware.broadcom.com/contact-us) catalog includes extra features and settings to configure the container with FIPS capabilities. You can configure the next environment variables: - `OPENSSL_FIPS`: whether OpenSSL runs in FIPS mode or not. `yes` (default), `no`. ## Notable Changes ### Starting January 16, 2024 - The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes. ## License Copyright © 2026 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --- ## File: bitnami/apisix-ingress-controller/README.md # Bitnami Secure Image for Apache APISIX Ingress Controller > Apache APISIX Ingress Controller integrates Apache APISIX in Kubernetes installations via the Ingress resource. Supports plugins and load balancing, amongst others. [Overview of Apache APISIX Ingress Controller](https://github.com/apache/apisix-ingress-controller) Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement. ## TL;DR ```console docker run -it --name apisix-ingress-controller bitnami/apisix-ingress-controller:latest ``` ## Why use Bitnami Secure Images? Those are hardened, minimal CVE images built and maintained by Bitnami. Bitnami Secure Images are based on the cloud-optimized, security-hardened enterprise [OS Photon Linux](https://vmware.github.io/photon/). Why choose BSI images? - Hardened secure images of popular open source software with Near-Zero Vulnerabilities - Vulnerability Triage & Prioritization with VEX Statements, KEV and EPSS Scores - Compliance focus with FIPS, STIG, and air-gap options, including secure bill of materials (SBOM) - Software supply chain provenance attestation through in-toto - First class support for the internet’s favorite Helm charts Each image comes with valuable security metadata. You can view the metadata in [our public catalog here](https://app-catalog.vmware.com/bitnami/apps). Note: Some data is only available with [commercial subscriptions to BSI](https://bitnami.com/). If you are looking for our previous generation of images based on Debian Linux, please see the [Bitnami Legacy registry](https://hub.docker.com/u/bitnamilegacy). ## Supported tags and respective `Dockerfile` links Learn more about the Bitnami tagging policy and the difference between rolling tags and immutable tags [in our documentation page](https://techdocs.broadcom.com/us/en/vmware-tanzu/application-catalog/tanzu-application-catalog/services/tac-doc/apps-tutorials-understand-rolling-tags-containers-index.html). ## Get this image The Bitnami Apache APISIX Ingress Controller Docker image is only available to [Bitnami Secure Images](https://bitnami.com) customers. ## Configuration The following section describes how to run commands ### Running commands To run commands inside this container you can use `docker run`, for example to execute `apisix-ingress-controller --help` you can follow the example below: ```console docker run --rm --name apisix-ingress-controller bitnami/apisix-ingress-controller:latest --help ``` Check the [official Apache APISIX Ingress Controller documentation](https://github.com/apache/apisix-ingress-controllerdocs/) for more information about how to use Apache APISIX Ingress Controller. ### FIPS configuration in Bitnami Secure Images The Bitnami Apache APISIX Ingress Controller Docker image from the [Bitnami Secure Images](https://go-vmware.broadcom.com/contact-us) catalog includes extra features and settings to configure the container with FIPS capabilities. You can configure the next environment variables: - `OPENSSL_FIPS`: whether OpenSSL runs in FIPS mode or not. `yes` (default), `no`. - `GODEBUG`: controls Go FIPS mode. Use `fips140=only` (restricted), `fips140=on` (relaxed), or `fips140=off` (disabled). ## Notable Changes ### Starting January 16, 2024 - The `docker-compose.yaml` file has been removed, as it was solely intended for internal testing purposes. ## License Copyright © 2026 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.