DDEV Silo

This add-on integrates Silo, a drop-in replacement for MinIO, into your DDEV project.

It is based on the ddev/ddev-minio add-on, which has been archived because the upstream MinIO repository is archived and the minio/minio Docker image is gone. The add-on keeps the MinIO names working, so projects using ddev-minio can switch without changing their configuration (see Migrating from ddev-minio).

Overview

Silo is an S3-compatible object storage system and a drop-in replacement for MinIO. It is capable of working with unstructured data such as photos, videos, log files, backups, and container images.

Installation

ddev add-on get CandoImage/ddev-silo
ddev restart

After installation, make sure to commit the .ddev directory to version control.

Usage

A small minio service is also part of the project, for compatibility with ddev-minio setups. It runs no server of its own and forwards ports 9090 and 10101 to silo. So http://minio:10101, ddev exec -s minio ..., ddev ssh -s minio and hooks with service: minio keep working, and inside it localhost:10101 and mc behave as in the silo container.

Console credentials

Either login works:

The ddevsilo user is created by a post-start hook in .ddev/config.silo.yaml. It can also be used as S3 access key / secret.

File access

Project docker instances can access the S3 API via http://silo:10101 (http://minio:10101 works too).

DDEV router is configured to proxy the requests to https://<project>.ddev.site:10101 to the S3 API.

Example URLs for accessing files are

Connecting from PHP

Installation

Since Silo is S3 compatible you can use AWS PHP SDK. Install it with composer:

ddev composer require aws/aws-sdk-php

Basic usage

<?php

require __DIR__ . '/vendor/autoload.php';

$s3 = new \Aws\S3\S3Client([
    'endpoint' => 'http://silo:10101',
    'credentials' => [
        'key' => 'ddevminio',
        'secret' => 'ddevminio',
    ],
    'region' => 'us-east-1',
    'version' => 'latest',
    'use_path_style_endpoint' => true,
]);

$bucketName = 'ddev-silo';

if (!$s3->doesBucketExist($bucketName)) {
    $s3->createBucket([
        'Bucket' => $bucketName,
    ]);
}

$s3->putObject([
    'Bucket' => $bucketName,
    'Key' => 'ddev-test',
    'Body' => 'DDEV Silo is working!',
]);

$object = $s3->getObject([
    'Bucket' => $bucketName,
    'Key' => 'ddev-test',
]);

echo $object['Body'];

Advanced Customization

To change the Docker image:

ddev dotenv set .ddev/.env.silo --silo-docker-image=pgsty/silo:latest
ddev add-on get CandoImage/ddev-silo
ddev restart

An existing MINIO_DOCKER_IMAGE setting in .ddev/.env.minio is still honored when SILO_DOCKER_IMAGE is not set.

You can modify .ddev/docker-compose.silo.yaml directly by removing the #ddev-generated line, but it’s recommended to use a separate .ddev/docker-compose.silo_extra.yaml file for overrides, for example:

services:
  silo:
    command: server --console-address :9090 --address :10101

configs:
  mc-config.json:
    content: |
      {
        "version": "10",
        "aliases": {
          "silo": {
            "url": "http://localhost:10101",
            "accessKey": "ddevminio",
            "secretKey": "ddevminio",
            "api": "s3v4",
            "path": "auto"
          },
          "minio": {
            "url": "http://localhost:10101",
            "accessKey": "ddevminio",
            "secretKey": "ddevminio",
            "api": "s3v4",
            "path": "auto"
          }
        }
      }

Migrating from ddev-minio

Install this add-on over the existing one and restart:

ddev add-on get CandoImage/ddev-silo
ddev restart

The installer removes the old #ddev-generated MinIO files and the old ddev-<project>-minio container. Your data is kept: Silo uses the same ddev-<project>-minio Docker volume.

The old minio add-on is also unregistered, so it no longer shows up in ddev add-on list --installed. There’s no need to run ddev add-on remove minio afterwards.

What keeps working unchanged:

What changes:

• The server runs in the silo service. ddev logs -s silo shows the server logs; ddev logs -s minio only shows the alias service.
• The minio alias service shares the data volume and mc, but not the server itself, so anything that needs the server binary (silo) must run in the silo service.
• Overrides in .ddev/docker-compose.minio_extra.yaml that target the minio service need to target silo instead.
• If a modified (non-#ddev-generated) docker-compose.minio.yaml or commands/minio/mc is present, the installer stops and asks you to remove it.

Credits

ddev-minio

• Contributed by Oblak Studio
• Maintained by the DDEV team

ddev-silo

• Contributed by Cando Image GmbH