# Hosting Platforms

**Package:** Laravel Compose | **Version:** 1 | **URL:** https://mozex.dev/docs/laravel-compose/v1/deploying/hosting-platforms

---

The default setup is the simplest one: the containers run on the server that runs the app, the deploy user talks to the local daemon, and `compose:redeploy` is one line in the deploy script. Everything below is about where that line goes and what each platform adds.

## Ploi

Ploi installs Docker with one click on an existing server or as a "Docker server" type, and adds the `ploi` user (or the custom system user you gave the site) to the docker group.

Put the redeploy in your deploy script, after the new release is ready:

```bash
php artisan compose:redeploy
```

If you drive deploys through Composer scripts, it's the first entry of `deploy:after`.

Ploi's panel keeps its containers in `/home/{user}/containers/{name}`, where `{user}` is the system user the site runs as. Point the link directory there and every stack gets a link named after itself, so the panel's container screen shows the logs of what the deploy just created:

```
COMPOSE_LINK_DIRECTORY=/home/ploi/containers
```

Two things to know about that directory:

- The panel creates it as root the first time you open the containers screen. The deploy user then can't write the link. Run `sudo chown ploi:ploi /home/ploi/containers` once (with your user in place of `ploi`); `compose:doctor` prints that exact command when it applies. Until it's done, the link is skipped with a line in the deploy log and the container still comes up.
- An empty directory the panel created for a stack gives way to the link. A directory that already has files in it doesn't: the package never deletes content, so move the files away first, or the link stays skipped.
- Ploi stores its own copy of the compose YAML in its database, and a container deploy started from the panel is likely to write that copy into the linked directory, which is your release tree. Use the panel for logs and status. Deploy from the app.

## Laravel Forge

Install Docker on the server with Docker's own install script and add the `forge` user to the docker group. Then add the line to the site's deploy script, after `php artisan migrate --force`:

```bash
php artisan compose:redeploy
```

Forge has no container screen, so `compose:status` and `compose:logs` are how you look at the stacks. The link directory can stay unset.

## Envoyer

Add a "Run script" hook on the "Activate New Release" action:

```bash
cd {{ release }} && php artisan compose:redeploy
```

The env file is written into the release that runs the command, which is the one about to go live.

## Plain SSH, Deployer, CI runners

Any post-deploy step that runs Artisan in the new release directory works. The command is safe to rerun, so a retry after a flaky network is fine.

## Per-host switches

The same deploy script runs on production, staging, and a laptop, and only some of those run Docker. Two switches handle it:

- `enabled()` on the stack, reading a config value such as `MANAGE_MEILISEARCH_CONTAINER=true`. The stack is skipped elsewhere.
- `COMPOSE_ENABLED=false`, which skips every stack on that host.

A skipped stack prints one line and exits 0, so CI never fails for lack of a daemon.

## The release directory

Containers are created from the release directory that ran the redeploy. Named volumes don't care. A bind mount of a file inside the stack directory does: it keeps pointing at that release. If your deploy prunes old releases, keep enough of them that the running container's release survives, or avoid bind mounts in stacks that live long. The next redeploy moves everything to the new release anyway.

---

## Table of Contents

- [Introduction](https://mozex.dev/docs/laravel-compose/v1)
- [AI Integration](https://mozex.dev/docs/laravel-compose/v1/ai-integration)
- [Support Us](https://mozex.dev/docs/laravel-compose/v1/support-us)
- [Requirements](https://mozex.dev/docs/laravel-compose/v1/requirements)
- [Changelog](https://mozex.dev/docs/laravel-compose/v1/changelog)
- [Contributing](https://mozex.dev/docs/laravel-compose/v1/contributing)
- [Questions & Issues](https://mozex.dev/docs/laravel-compose/v1/questions-and-issues)
- [About Mozex](https://mozex.dev/docs/laravel-compose/v1/about)
- [Installation](https://mozex.dev/docs/laravel-compose/v1/installation)
- [Configuration](https://mozex.dev/docs/laravel-compose/v1/configuration)

### Stacks

- [Defining a Stack](https://mozex.dev/docs/laravel-compose/v1/stacks/defining-a-stack)
- [Discovery](https://mozex.dev/docs/laravel-compose/v1/stacks/discovery)
- [Environment Files](https://mozex.dev/docs/laravel-compose/v1/stacks/environment-files)
- [Compose Files](https://mozex.dev/docs/laravel-compose/v1/stacks/compose-files)

### Deploying

- [Redeploy](https://mozex.dev/docs/laravel-compose/v1/deploying/redeploy)
- [Hosting Platforms](https://mozex.dev/docs/laravel-compose/v1/deploying/hosting-platforms)
- [Remote Daemons](https://mozex.dev/docs/laravel-compose/v1/deploying/remote-daemons)
- [Doctor](https://mozex.dev/docs/laravel-compose/v1/deploying/doctor)

### Operating

- [Status, Logs, and Down](https://mozex.dev/docs/laravel-compose/v1/operating/status-logs-down)
- [Health Check](https://mozex.dev/docs/laravel-compose/v1/operating/health-check)
- [Events](https://mozex.dev/docs/laravel-compose/v1/operating/events)
- [Testing](https://mozex.dev/docs/laravel-compose/v1/operating/testing)

### Recipes

- [Meilisearch](https://mozex.dev/docs/laravel-compose/v1/recipes/meilisearch)
- [Telegram Bot API](https://mozex.dev/docs/laravel-compose/v1/recipes/telegram-bot-api)