Codespaces with php and mysql

[wdpspace]

🏷️ Discussion Type

Question

Body

Hi
How do I set up codespaces with a xampp type environment where I can code and test php mysql?
Ideally I'd like the data in the db to be persistent as well.
I looked in the templates when creating a new codespaces, but there is no php mysql option.
Appreciate any help!

[Albert23867]

You probably don't need XAMPP in Codespaces. I would just run PHP directly and set up MySQL separately. The main thing is to make sure the database is persistent, otherwise you might lose your data when the Codespace is recreated. A Docker setup with a volume could work well for this. I haven't used this exact setup a lot, but that's probably the direction I'd try.

[LuisGustavoCassioli]

You don't need to recreate a traditional XAMPP stack in GitHub Codespaces.

Codespaces is designed around Dev Containers, so the recommended approach is to containerize your development environment instead of installing everything into a single image.

A typical setup would look like this:

• PHP + Apache (or PHP-FPM + Nginx) for your application
• MySQL or MariaDB as a separate service
• A named Docker volume for the database, so your data persists across container rebuilds
• A .devcontainer/ directory containing your devcontainer.json and docker-compose.yml

Example project structure:

.
├── .devcontainer/
│   ├── devcontainer.json
│   └── docker-compose.yml
├── src/
├── public/
└── ...

With this approach you get:

• ✅ A PHP development environment
• ✅ A persistent MySQL database
• ✅ An isolated and reproducible setup
• ✅ The ability to run the exact same environment locally with VS Code Dev Containers or anywhere Docker is available

If you're starting from scratch, I'd recommend using the official PHP Dev Container as your base and adding a MySQL service through Docker Compose. It's much closer to modern PHP development practices than trying to install XAMPP inside a Codespace.

[wgarciar3]

Both directions above are right — Dev Containers + Docker Compose, not XAMPP. Here's a concrete starting point:

// .devcontainer/devcontainer.json
{
  "name": "php-mysql",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/workspace"
}

# .devcontainer/docker-compose.yml
services:
  app:
    image: mcr.microsoft.com/devcontainers/php:8.3
    volumes:
      - ..:/workspace:cached
    command: sleep infinity

  db:
    image: mysql:8.0
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: secret
      MYSQL_DATABASE: app
    volumes:
      - db-data:/var/lib/mysql

volumes:
  db-data:

One thing neither answer above mentions: the persistence caveat only covers part of the lifecycle. A named volume (db-data here) survives a rebuild container — so your data is safe across most day-to-day work. It does not survive deleting the Codespace itself. If you need the data to outlive the Codespace's lifetime (not just rebuilds), dump it somewhere external (a mysqldump committed to a branch, or an external managed DB) — don't rely on the Codespace's disk as your only copy.

[CristianOlivera1]

Building on the excellent docker-compose.yml baseline provided by @wgarciar3, you need to solve two critical operational things to truly match a XAMPP experience in Codespaces: port forwarding (to view your PHP site) and the database host configuration inside your PHP script.

Here is the fully optimized and production-ready setup for your .devcontainer/ folder.

1. Updated .devcontainer/devcontainer.json

You must explicitly tell Codespaces to forward ports (typically 8080 for Apache/PHP and 3306 for MySQL) so you can access them via your browser or a database client like TablePlus or DBeaver.

{
  "name": "PHP & MySQL (XAMPP Alternative)",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/workspace",
  "forwardPorts": [8080, 3306],
  "portsAttributes": {
    "8080": {
      "label": "PHP Web Server",
      "onAutoForward": "openBrowser"
    },
    "3306": {
      "label": "MySQL Database",
      "onAutoForward": "ignore"
    }
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "bmewburn.vscode-intelephense-client",
        "mtxr.sqltools",
        "mtxr.sqltools-driver-mysql"
      ]
    }
  }
}

2. Updated .devcontainer/docker-compose.yml

Instead of using sleep infinity, we change the image tag to a variant that includes Apache (-apache) and map port 8080 to Apache's default port 80.

version: '3.8'

services:
  app:
    image: ://microsoft.com
    volumes:
      - ..:/var/www/html:cached
    ports:
      - "8080:80"

  db:
    image: mysql:8.0
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: root_password
      MYSQL_DATABASE: my_local_db
      MYSQL_USER: dev_user
      MYSQL_PASSWORD: dev_password
    ports:
      - "3306:3306"
    volumes:
      - db-data:/var/lib/mysql

volumes:
  db-data:

Note: Notice that the volume maps to /var/www/html. This is standard for Apache, meaning if you create an index.php at the root of your repository, it will serve immediately.

3. How to Connect PHP to MySQL (The XAMPP difference)

In XAMPP, you usually connect to localhost or 127.0.0.1. In a Docker Compose multi-container architecture, the database host is the name of the service (db), not localhost.

Here is a quick snippet (index.php) to test your stack:

<?php
\$host = 'db'; // Match the service name in docker-compose.yml
\$user = 'dev_user';
\(pass = 'dev_password';\)db   = 'my_local_db';

try {
    pdo = new PDO("mysql:host=host;dbname=db;charset=utf8", user, \(pass);\)pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    echo "<h1>🚀 Connected successfully to the persistent MySQL database!</h1>";
} catch (PDOException \$e) {
    echo "❌ Connection failed: " . \$e->getMessage();
}

Summary of Life-cycle & Data Persistence:

1. Container Rebuilds: Modifying your Docker setup or extensions preserves data because db-data is an isolated Docker volume.
2. Codespace Stop/Start: Turning off your Codespace completely preserves everything (files, databases, configurations).
3. Codespace Deletion: As @wgarciar3 pointed out, if you explicitly delete the Codespace container from your GitHub dashboard, the volume dies with it. Keep structural DB changes version-controlled via SQL migration scripts or seeders in your repository!