I have tested this item 🔴 unsuccessfully on ae978af

I tested this PR twice in GitHub Codespaces. Both times, the environment built successfully and the Joomla installation page loaded via port 80, but the container crashed and became unavailable immediately after opening the site.

I have tested this item 🔴 unsuccessfully on ae978af

I tested this PR twice in GitHub Codespaces. Both times, the environment built successfully and the Joomla installation page loaded via port 80, but the container crashed and became unavailable immediately after opening the site.

Joomla installation page

then something has going wrong on yuor side , after finished the post create it will open the already installed joomla hoempage

Hi @alikon,

I tested this locally and found a stable way to auto-start Apache without causing the container to crash.

Changing command to apache2-foreground in docker-compose.yml binds the container lifecycle directly to Apache (which shuts down the whole Codespace if Apache exits or reloads).

Instead, keeping docker-compose.yml untouched and adding "postStartCommand": "service apache2 start" to .devcontainer/devcontainer.json seamlessly launches Apache in the background on start while keeping the container fully stable.

Here is the updated section for .devcontainer/devcontainer.json:

"postStartCommand": "service apache2 start",
"customizations": {

@alikon Could you please check @fyousefi comment? And this PR is DRAFT at the moment?

imho is better to change in docker compose that in devcontainer.json
opening this GitHub Codespace will get a fully functioning Apache server immediately upon container creation,
without relying on post-start scripts executing correctly

Hi @alikon,

As indicated by the PR title, this scope is specifically designed for GitHub Codespaces. In the architecture of devcontainers, lifecycle configurations and service automation should ideally reside within .devcontainer/devcontainer.json (such as using postStartCommand) rather than overriding the primary container command in docker-compose.yml.

Binding the main container process directly to apache2-foreground causes the entire Codespace container to crash and exit immediately if Apache reloads or encounters an initial request issue, leading to a loss of environment availability.

If a core Docker-level change is intended for broader container usage outside of Codespaces, it would be more appropriate to handle it in a separate PR with a distinct scope and fallback handling, while keeping Codespaces stable using standard lifecycle hooks.

then do an alternative PR, and let mantainers decide
i still stand with my change