Platform.sh User Documentation

PHP

Upsun Beta

Access our newest offering - Upsun!

Get your free trial by clicking the link below.

Get your Upsun free trial

Supported versions Anchor to this heading

You can select the major and minor version.

Patch versions are applied periodically for bug fixes and the like. When you deploy your app, you always get the latest available patches.

Grid and Dedicated Gen 3 Dedicated Gen 2
  • 8.3
  • 8.2
  • 8.1
  • 8.2
  • 8.1
  • 8.0

Note that from PHP versions 7.1 to 8.1, the images support the Zend Thread Safe (ZTS) version of PHP.

Specify the language Anchor to this heading

To use PHP, specify php as your app’s type:

.platform.app.yaml
type: 'php:<VERSION_NUMBER>'

For example:

.platform.app.yaml
type: 'php:8.3'

Deprecated versions Anchor to this heading

The following versions are deprecated. They’re available, but they aren’t receiving security updates from upstream and aren’t guaranteed to work. They’ll be removed in the future, so migrate to one of the supported versions.

Grid and Dedicated Gen 3 Dedicated Gen 2
  • 8.0
  • 7.4
  • 7.3
  • 7.2
  • 7.1
  • 7.0
  • 5.6
  • 5.5
  • 5.4
  • 7.4
  • 7.3
  • 7.2
  • 7.1
  • 7.0

Usage example Anchor to this heading

Configure your app to use PHP on Platform.sh.

1. Specify the version Anchor to this heading

Choose a supported version and add it to your app configuration:

.platform.app.yaml
type: 'php:8.3'

2. Serve your app Anchor to this heading

To serve your app, define what (and how) content should be served by setting the locations parameter.

Usually, it contains the two following (optional) keys:

  • root for the document root, the directory to which all requests for existing .php and static files (such as .css, .jpg) are sent.

  • passthru to define a front controller to handle nonexistent files. The value is a file path relative to the app root.

Adjust the locations block to fit your needs.

In the following example, all requests made to your site’s root (/) are sent to the public directory and nonexistent files are handled by app.php:

.platform.app.yaml
web:
    locations:
        '/':
            root: 'public'
            passthru: '/app.php'

See how to create a basic PHP app with a front controller. To have more control, you can define rules to specify which files you want to allow from which location.

Complete example Anchor to this heading

A complete basic app configuration looks like the following:

.platform.app.yaml
name: 'app'

type: 'php:8.3'

disk: 2048

web:
    locations:
        '/':
            root: 'public'
            passthru: '/app.php'

Dependencies Anchor to this heading

Up to PHP version 8.1, it’s assumed that you’re using Composer 1.x to manage dependencies. If you have a composer.json file in your code, the default build flavor is run:

composer --no-ansi --no-interaction install --no-progress --prefer-dist --optimize-autoloader

To use Composer 2.x on your project, either use PHP 8.2+ or, in your app configuration, add the following dependency:

.platform.app.yaml
dependencies:
    php:
        composer/composer: '^2'

Adding a dependency to the dependencies block makes it available globally. So you can then use included dependencies as commands within your app container. You can add multiple global dependencies to the dependencies block, such as Node.js.

If you want to have more control over Composer or if you don’t want to use Composer at all, adapt the build flavor. You can also use a private, authenticated third-party Composer repository.

Change the build flavor Anchor to this heading

If you need more control over the dependency management, you can either use your custom build flavor or interact with Composer itself through its environment variables.

You can remove the default build flavor and run your own commands for complete control over your build. Set the build flavor to none and add the commands you need to your build hook, as in the following example:

.platform.app.yaml
build:
    flavor: none

hooks:
    build: |
        set -e
        composer install --no-interaction --no-dev        

That installs production dependencies with Composer but not development dependencies. The same can be achieved by using the default build flavor and adding the COMPOSER_NO_DEV variable.

See more on build flavors.

Alternative repositories Anchor to this heading

In addition to the standard dependencies format, you can specify alternative repositories for Composer to use as global dependencies. So you can install a forked version of a global dependency from a custom repository.

To install from an alternative repository:

  1. Set an explicit require block:
.platform.app.yaml
dependencies:
    php:
        require:
            "platformsh/client": "2.x-dev"

This is equivalent to composer require platform/client 2.x-dev.

  1. Add the repository to use:
.platform.app.yaml
repositories:
    - type: vcs
      url: "git@github.com:platformsh/platformsh-client-php.git"

That installs platformsh/client from the specified repository URL as a global dependency.

For example, to install Composer 2 and the platform/client 2.x-dev library from a custom repository, use the following:

.platform.app.yaml
dependencies:
    php:
        composer/composer: '^2'
        require:
            "platformsh/client": "2.x-dev"
        repositories:
            - type: vcs
              url: "git@github.com:platformsh/platformsh-client-php.git"

Connect to services Anchor to this heading

The following examples show how to use PHP to access various services. The individual service pages have more information on configuring each service.

<?php

declare(strict_types=1);

use Elasticsearch\ClientBuilder;
use Platformsh\ConfigReader\Config;

// Create a new config object to ease reading the Platform.sh environment variables.
// You can alternatively use getenv() yourself.
$config = new Config();

// Get the credentials to connect to the Elasticsearch service.
$credentials = $config->credentials('elasticsearch');

try {
    // The Elasticsearch library lets you connect to multiple hosts.
    // On Platform.sh Standard there is only a single host so just
    // register that.
    $hosts = [
        [
            'scheme' => $credentials['scheme'],
            'host' => $credentials['host'],
            'port' => $credentials['port'],
        ]
    ];

    // Create an Elasticsearch client object.
    $builder = ClientBuilder::create();
    $builder->setHosts($hosts);
    $client = $builder->build();

    $index = 'my_index';
    $type = 'People';

    // Index a few document.
    $params = [
        'index' => $index,
        'type' => $type,
    ];

    $names = ['Ada Lovelace', 'Alonzo Church', 'Barbara Liskov'];

    foreach ($names as $name) {
        $params['body']['name'] = $name;
        $client->index($params);
    }

    // Force just-added items to be indexed.
    $client->indices()->refresh(array('index' => $index));


    // Search for documents.
    $result = $client->search([
        'index' => $index,
        'type' => $type,
        'body' => [
            'query' => [
                'match' => [
                    'name' => 'Barbara Liskov',
                ],
            ],
        ],
    ]);

    if (isset($result['hits']['hits'])) {
        print <<<TABLE
<table>
<thead>
<tr><th>ID</th><th>Name</th></tr>
</thead>
<tbody>
TABLE;
        foreach ($result['hits']['hits'] as $record) {
            printf("<tr><td>%s</td><td>%s</td></tr>\n", $record['_id'], $record['_source']['name']);
        }
        print "</tbody>\n</table>\n";
    }

    // Delete documents.
    $params = [
        'index' => $index,
        'type' => $type,
    ];

    $ids = array_map(function($row) {
        return $row['_id'];
    }, $result['hits']['hits']);

    foreach ($ids as $id) {
        $params['id'] = $id;
        $client->delete($params);
    }

} catch (Exception $e) {
    print $e->getMessage();
}
<?php

declare(strict_types=1);

use Platformsh\ConfigReader\Config;

// Create a new config object to ease reading the Platform.sh environment variables.
// You can alternatively use getenv() yourself.
$config = new Config();

// Get the credentials to connect to the Memcached service.
$credentials = $config->credentials('memcached');

try {
    // Connecting to Memcached server.
    $memcached = new Memcached();
    $memcached->addServer($credentials['host'], $credentials['port']);
    $memcached->setOption(Memcached::OPT_BINARY_PROTOCOL, true);

    $key = "Deploy day";
    $value = "Friday";

    // Set a value.
    $memcached->set($key, $value);

    // Read it back.
    $test = $memcached->get($key);

    printf('Found value <strong>%s</strong> for key <strong>%s</strong>.', $test, $key);

} catch (Exception $e) {
    print $e->getMessage();
}
<?php

declare(strict_types=1);

use Platformsh\ConfigReader\Config;
use MongoDB\Client;

// Create a new config object to ease reading the Platform.sh environment variables.
// You can alternatively use getenv() yourself.
$config = new Config();

// The 'database' relationship is generally the name of primary database of an application.
// It could be anything, though, as in the case here here where it's called "mongodb".
$credentials = $config->credentials('mongodb');

try {

    $server = sprintf('%s://%s:%s@%s:%d/%s',
        $credentials['scheme'],
        $credentials['username'],
        $credentials['password'],
        $credentials['host'],
        $credentials['port'],
        $credentials['path']
    );

    $client = new Client($server);
    $collection = $client->main->starwars;

    $result = $collection->insertOne([
        'name' => 'Rey',
        'occupation' => 'Jedi',
    ]);

    $id = $result->getInsertedId();

    $document = $collection->findOne([
        '_id' => $id,
    ]);

    // Clean up after ourselves.
    $collection->drop();

    printf("Found %s (%s)<br />\n", $document->name, $document->occupation);

} catch (\Exception $e) {
    print $e->getMessage();
}
<?php

declare(strict_types=1);

use Platformsh\ConfigReader\Config;

// Create a new config object to ease reading the Platform.sh environment variables.
// You can alternatively use getenv() yourself.
$config = new Config();

// The 'database' relationship is generally the name of primary SQL database of an application.
// That's not required, but much of our default automation code assumes it.
$credentials = $config->credentials('database');

try {
    // Connect to the database using PDO.  If using some other abstraction layer you would
    // inject the values from $database into whatever your abstraction layer asks for.
    $dsn = sprintf('mysql:host=%s;port=%d;dbname=%s', $credentials['host'], $credentials['port'], $credentials['path']);
    $conn = new \PDO($dsn, $credentials['username'], $credentials['password'], [
        // Always use Exception error mode with PDO, as it's more reliable.
        \PDO::ATTR_ERRMODE => \PDO::ERRMODE_EXCEPTION,
        // So we don't have to mess around with cursors and unbuffered queries by default.
        \PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => TRUE,
        // Make sure MySQL returns all matched rows on update queries including
        // rows that actually didn't have to be updated because the values didn't
        // change. This matches common behavior among other database systems.
        \PDO::MYSQL_ATTR_FOUND_ROWS => TRUE,
    ]);

    // Creating a table.
    $sql = "CREATE TABLE People (
      id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
      name VARCHAR(30) NOT NULL,
      city VARCHAR(30) NOT NULL
      )";
    $conn->query($sql);

    // Insert data.
    $sql = "INSERT INTO People (name, city) VALUES
        ('Neil Armstrong', 'Moon'),
        ('Buzz Aldrin', 'Glen Ridge'),
        ('Sally Ride', 'La Jolla');";
    $conn->query($sql);

    // Show table.
    $sql = "SELECT * FROM People";
    $result = $conn->query($sql);
    $result->setFetchMode(\PDO::FETCH_OBJ);

    if ($result) {
        print <<<TABLE
<table>
<thead>
<tr><th>Name</th><th>City</th></tr>
</thead>
<tbody>
TABLE;
        foreach ($result as $record) {
            printf("<tr><td>%s</td><td>%s</td></tr>\n", $record->name, $record->city);
        }
        print "</tbody>\n</table>\n";
    }

    // Drop table
    $sql = "DROP TABLE People";
    $conn->query($sql);

} catch (\Exception $e) {
    print $e->getMessage();
}
<?php

declare(strict_types=1);

use Platformsh\ConfigReader\Config;

// Create a new config object to ease reading the Platform.sh environment variables.
// You can alternatively use getenv() yourself.
$config = new Config();

// The 'database' relationship is generally the name of primary SQL database of an application.
// It could be anything, though, as in the case here here where it's called "postgresql".
$credentials = $config->credentials('postgresql');

try {
    // Connect to the database using PDO.  If using some other abstraction layer you would
    // inject the values from $database into whatever your abstraction layer asks for.
    $dsn = sprintf('pgsql:host=%s;port=%d;dbname=%s', $credentials['host'], $credentials['port'], $credentials['path']);
    $conn = new \PDO($dsn, $credentials['username'], $credentials['password'], [
        // Always use Exception error mode with PDO, as it's more reliable.
        \PDO::ATTR_ERRMODE => \PDO::ERRMODE_EXCEPTION,
    ]);

    $conn->query("DROP TABLE IF EXISTS People");

    // Creating a table.
    $sql = "CREATE TABLE IF NOT EXISTS People (
      id SERIAL PRIMARY KEY,
      name VARCHAR(30) NOT NULL,
      city VARCHAR(30) NOT NULL
      )";
    $conn->query($sql);

    // Insert data.
    $sql = "INSERT INTO People (name, city) VALUES
        ('Neil Armstrong', 'Moon'),
        ('Buzz Aldrin', 'Glen Ridge'),
        ('Sally Ride', 'La Jolla');";
    $conn->query($sql);

    // Show table.
    $sql = "SELECT * FROM People";
    $result = $conn->query($sql);
    $result->setFetchMode(\PDO::FETCH_OBJ);

    if ($result) {
        print <<<TABLE
<table>
<thead>
<tr><th>Name</th><th>City</th></tr>
</thead>
<tbody>
TABLE;
        foreach ($result as $record) {
            printf("<tr><td>%s</td><td>%s</td></tr>\n", $record->name, $record->city);
        }
        print "</tbody>\n</table>\n";
    }

    // Drop table.
    $sql = "DROP TABLE People";
    $conn->query($sql);

} catch (\Exception $e) {
    print $e->getMessage();
}
<?php

declare(strict_types=1);

use Platformsh\ConfigReader\Config;
use PhpAmqpLib\Connection\AMQPStreamConnection;
use PhpAmqpLib\Message\AMQPMessage;

// Create a new config object to ease reading the Platform.sh environment variables.
// You can alternatively use getenv() yourself.
$config = new Config();

// Get the credentials to connect to the RabbitMQ service.
$credentials = $config->credentials('rabbitmq');

try {

    $queueName = 'deploy_days';

    // Connect to the RabbitMQ server.
    $connection = new AMQPStreamConnection($credentials['host'], $credentials['port'], $credentials['username'], $credentials['password']);
    $channel = $connection->channel();

    $channel->queue_declare($queueName, false, false, false, false);

    $msg = new AMQPMessage('Friday');
    $channel->basic_publish($msg, '', 'hello');

    echo "[x] Sent 'Friday'<br/>\n";

    // In a real application you't put the following in a separate script in a loop.
    $callback = function ($msg) {
        printf("[x] Deploying on %s<br />\n", $msg->body);
    };

    $channel->basic_consume($queueName, '', false, true, false, false, $callback);

    // This blocks on waiting for an item from the queue, so comment it out in this demo script.
    //$channel->wait();

    $channel->close();
    $connection->close();

} catch (Exception $e) {
    print $e->getMessage();
}
<?php

declare(strict_types=1);

use Platformsh\ConfigReader\Config;

// Create a new config object to ease reading the Platform.sh environment variables.
// You can alternatively use getenv() yourself.
$config = new Config();

// Get the credentials to connect to the Redis service.
$credentials = $config->credentials('redis');

try {
    // Connecting to Redis server.
    $redis = new Redis();
    $redis->connect($credentials['host'], $credentials['port']);

    $key = "Deploy day";
    $value = "Friday";

    // Set a value.
    $redis->set($key, $value);

    // Read it back.
    $test = $redis->get($key);

    printf('Found value <strong>%s</strong> for key <strong>%s</strong>.', $test, $key);

} catch (Exception $e) {
    print $e->getMessage();
}
<?php
declare(strict_types=1);

use Platformsh\ConfigReader\Config;
use Solarium\Client;

// Create a new config object to ease reading the Platform.sh environment variables.
// You can alternatively use getenv() yourself.
$config = new Config();

// Get the credentials to connect to the Solr service.
$credentials = $config->credentials('solr');

try {

    $config = [
        'endpoint' => [
            'localhost' => [
                'host' => $credentials['host'],
                'port' => $credentials['port'],
                'path' => "/" . $credentials['path'],
            ]
        ]
    ];

    $client = new Client($config);

    // Add a document
    $update = $client->createUpdate();

    $doc1 = $update->createDocument();
    $doc1->id = 123;
    $doc1->name = 'Valentina Tereshkova';

    $update->addDocuments(array($doc1));
    $update->addCommit();

    $result = $client->update($update);
    print "Adding one document. Status (0 is success): " .$result->getStatus(). "<br />\n";

    // Select one document
    $query = $client->createQuery($client::QUERY_SELECT);
    $resultset = $client->execute($query);
    print  "Selecting documents (1 expected): " .$resultset->getNumFound() . "<br />\n";

    // Delete one document
    $update = $client->createUpdate();

    $update->addDeleteById(123);
    $update->addCommit();
    $result = $client->update($update);
    print "Deleting one document. Status (0 is success): " .$result->getStatus(). "<br />\n";

} catch (Exception $e) {
    print $e->getMessage();
}

Configuration reader Anchor to this heading

While you can read the environment directly from your app, you might want to use thePHP configuration reader library. It decodes service credentials, the correct port, and other information for you.

PHP settings Anchor to this heading

You can configure your PHP-FPM runtime configuration by specifying the runtime in your app configuration.

In addition to changes in runtime, you can also change the PHP settings. Some commonly used settings are:

Name Default Description
max_execution_time 300 The maximum execution time, in seconds, for your PHP scripts and apps. A value of 0 means there are no time limits.
max_file_uploads 20 The maximum number of files that can be uploaded in each request.
max_input_time 60 The maximum time in seconds that your script is allowed to receive input (such as for file uploads). A value of -1 means there are no time limits.
max_input_vars 1000 The maximum number of input variables that are accepted in each request.
memory_limit 128M The memory limit, in megabytes, for PHP. Ensure that the PHP memory limit is set to a lower value than your environment’s memory.
post_max_size 64M The maximum size, in megabytes, per uploaded file. To upload larger files, increase the value.
zend.assertions -1 Assertions are optimized and have no impact at runtime. Set assertions to 1 for your local development system. See more on assertions.
opcache.memory_consumption 64 The number of megabytes available for the OPcache. For large apps with many files, increase this value.
opcache.validate_timestamps On If your app doesn’t generate compiled PHP, you can disable this setting.

Retrieve the default values Anchor to this heading

To retrieve the default PHP values, run the following CLI command:

platform ssh "php --info"

To get specific default values, use grep. For example, to get the value for opcache.memory_consumption, run the following command:

platform ssh "php --info" | grep opcache.memory_consumption

Retrieve the settings Anchor to this heading

To see the settings used on your environment:

  1. Find the PHP configuration files with the following CLI command:

    platform ssh "php --ini"

    The output is something like the following:

    Configuration File (php.ini) Path: /etc/php/8.0-zts/cli
    Loaded Configuration File:         /etc/php/8.0-zts/cli/php.ini
    Scan for additional .ini files in: /etc/php/8.0-zts/cli/conf.d
    Additional .ini files parsed:      (none)
  2. Display the configuration file by adapting the following command with the output from step 1:

    platform ssh "cat LOADED_CONFIGURATION_FILE_PATH"

Customize PHP settings Anchor to this heading

For Dedicated Gen 2, see the configuration options.

You can customize PHP values for your app in two ways. The recommended method is to use variables.

Set variables to override PHP settings for a given environment using the CLI.

For example, to set the PHP memory limit to 256 MB on a specific environment, run the following CLI command:

platform variable:create --level environment \
    --prefix php --name memory_limit \
    --value 256M --environment ENVIRONMENT_NAME \
    --no-interaction

For more information, see how to use PHP-specific variables.

You can provide a custom php.ini file at the app root. Using this method isn’t recommended since it offers less flexibility and is more error-prone. Consider using variables instead.

For example, to change the PHP memory limit, use the following configuration:

php.ini
memory_limit = 256M

If you’re using PHP-CLI, you need to take into account the default settings of PHP-CLI when you customize your PHP settings. The default settings of PHP-CLI can’t be overwritten and are the following:

max_execution_time=0
max_input_time=-1
memory_limit=-1

Disable functions for security Anchor to this heading

A common recommendation for securing PHP installations is disabling built-in functions frequently used in remote attacks. By default, Platform.sh doesn’t disable any functions.

If you’re sure a function isn’t needed in your app, you can disable it.

For example, to disable pcntl_exec and pcntl_fork, add the following to your app configuration:

.platform.app.yaml
variables:
    php:
        disable_functions: "pcntl_exec,pcntl_fork"

Common functions to disable include:

Name Description
create_function This function has been replaced by anonymous functions and shouldn’t be used anymore.
exec, passthru, shell_exec, system, proc_open, popen These functions allow a PHP script to run a bash shell command. Rarely used by web apps except for build scripts that might need them.
pcntl_* The pcntl_* functions are responsible for process management. Most of them cause a fatal error if used within a web request. Cron tasks or workers may need them. Most are usually safe to disable.
curl_exec, curl_multi_exec These functions allow a PHP script to make arbitrary HTTP requests. If you’re using HTTP libraries such as Guzzle, don’t disable them.
show_source This function shows a syntax highlighted version of a named PHP source file. Rarely useful outside of development.

Execution mode Anchor to this heading

PHP has two execution modes you can choose from:

  • The command line interface mode (PHP-CLI) is the mode used for command line scripts and standalone apps. This is the mode used when you’re logged into your container via SSH, for crons, and usually also for alternate start commands. To use PHP-CLI, run your script with php PATH_TO_SCRIPT, where PATH_TO_SCRIPT is a file path relative to the app root.
  • The Common Gateway Interface mode (PHP-CGI) is the mode used for web apps and web requests. This is the default mode when the start command isn’t explicitly set. To use PHP-CGI, run your script with a symlink: /usr/bin/start-php-app PATH_TO_SCRIPT, where PATH_TO_SCRIPT is a file path relative to the app root. With PHP-CGI, PHP is run using the FastCGI Process Manager (PHP-FPM).

Alternate start commands Anchor to this heading

To specify an alternative process to run your code, set a start command. For more information about the start command, see the web commands reference.

By default, start commands use PHP-CLI. Find out how and when to use each execution mode.

Note that the start command must run in the foreground and is executed before the deploy hook. That means that PHP-FPM can’t run simultaneously with another persistent process such as ReactPHP or Amp. If you need multiple processes, they have to run in separate containers.

See some generic examples on how to use alternate start commands:

  1. Add your script in a PHP file.
  2. Specify an alternative start command by adapting the following:
.platform.app.yaml
web:
    commands:
        start: /usr/bin/start-php-app PATH_TO_APP

PATH_TO_APP is a file path relative to the app root.

  1. Add your web server’s code in a PHP file.

  2. Specify an alternative start command by adapting the following:

.platform.app.yaml
web:
    commands:
        start: /usr/bin/start-php-app PATH_TO_APP

PATH_TO_APP is a file path relative to the app root.

  1. Configure the container to listen on a TCP socket:
.platform.app.yaml
web:
    upstream:
        socket_family: tcp
        protocol: http

When you listen on a TCP socket, the $PORT environment variable is automatically set. See more options on how to configure where requests are sent. You might have to configure your app to connect via the $PORT TCP socket, especially when using web servers such as Swoole or Roadrunner.

  1. Optional: Override redirects to let the custom web server handle them:
.platform.app.yaml
locations:
    "/":
        passthru: true
        scripts: false
        allow: false

To execute runtime-specific tasks (such as clearing cache) before your app starts, follow these steps:

  1. Create a separate shell script that includes all the commands to be run.

  2. Specify an alternative start command by adapting the following:

.platform.app.yaml
web:
    commands:
        start: bash PATH_TO_SCRIPT && /usr/bin/start-php-app PATH_TO_APP

PATH_TO_SCRIPT is the bash script created in step 1. Both PATH_TO_SCRIPT and PATH_TO_APP are file paths relative to the app root.

Foreign function interfaces Anchor to this heading

PHP 7.4 introduced support for foreign function interfaces (FFIs). FFIs allow your PHP program to call routines or use services written in C or Rust.

Note: FFIs are only intended for advanced use cases. Use with caution.

If you are using C code, you need .so library files. Either place these files directly in your repository or compile them in a makefile using gcc in your build hook. Note: The .so library files shouldn’t be located in a publicly accessible directory.

If you are compiling Rust code, use the build hook to install Rust.

To leverage FFIs, follow these steps:

  1. Enable and configure OPcache preloading.

  2. Enable the FFI extension:

.platform.app.yaml
runtime:
    extensions:
        - ffi
  1. Make sure that your preload script calls the FFI::load() function. Using this function in preload is considerably faster than loading the linked library on each request or script run.

  2. If you are running FFIs from the command line, enable the preloader by adding the following configuration:

.platform.app.yaml
variables:
    php:
        opcache.enable_cli: true
  1. Run your script with the following command:

    php CLI_SCRIPT

See complete working examples for C and Rust.

Project templates Anchor to this heading

The following list shows templates available for PHP apps.

A template is a starting point for building your project. It should help you get a project ready for production.

Drupal 10

Drupal 10

This template builds Drupal 10 using the "Drupal Recommended" Composer project. It is pre-configured to use MariaDB and Redis for caching. The Drupal installer will skip asking for database credentials as they are already provided.

Drupal is a flexible and extensible PHP-based CMS framework.

Features:

  • PHP 8.1
  • MariaDB 10.4
  • Redis 6
  • Drush included
  • Automatic TLS certificates
  • Composer-based build

View the repository on GitHub.

Drupal 9

Drupal 9

This template builds Drupal 9 using the "Drupal Recommended" Composer project. It is pre-configured to use MariaDB and Redis for caching. The Drupal installer will skip asking for database credentials as they are already provided.

Drupal is a flexible and extensible PHP-based CMS framework.

Features:

  • PHP 8.0
  • MariaDB 10.4
  • Redis 6
  • Drush included
  • Automatic TLS certificates
  • Composer-based build

View the repository on GitHub.

GovCMS 9

GovCMS 9

This template builds the Australian government's GovCMS Drupal 9 distribution using the Drupal Composer project for better flexibility. It is pre-configured to use MariaDB and Redis for caching. The Drupal installer will skip asking for database credentials as they are already provided.

GovCMS is a Drupal distribution built for the Australian government, and includes configuration optimized for managing government websites.

Features:

  • PHP 8.0
  • MariaDB 10.4
  • Redis 6
  • Drush included
  • Automatic TLS certificates
  • Composer-based build

View the repository on GitHub.

Laravel

Laravel

This template provides a basic Laravel skeleton. It comes pre-configured to use a MariaDB database and Redis for caching and sessions using a Laravel-specific bridge library that runs during Composer autoload. The public files symlink is also replaced with a custom web path definition so it is unnecessary. It is intended for you to use as a starting point and modify for your own needs.

Laravel is an opinionated, integrated rapid-application-development framework for PHP.

Features:

  • PHP 8.0
  • MariaDB 10.4
  • Redis 5.0
  • Automatic TLS certificates
  • Composer-based build

View the repository on GitHub.

Magento 2 Community Edition

Magento 2 Community Edition

This template builds Magento 2 CE on Platform.sh. It includes additional scripts to customize Magento to run effectively in a build-and-deploy environment. A MariaDB database and Redis cache server come pre-configured and work out of the box. The installer has been modified to not ask for database information. Background workers are run using a worker container rather than via cron.

Magento is a fully integrated ecommerce system and web store written in PHP. This is the Open Source version.

Features:

  • PHP 7.2
  • MariaDB 10.2
  • Redis 3.2
  • Dedicated worker instance for background processing
  • Automatic TLS certificates
  • Composer-based build

View the repository on GitHub.

Sylius

Sylius

This template builds a Sylius application for Platform.sh, which can be used as a starting point for developing complex e-commerce applications.

Sylius is a modern e-commerce solution for PHP, based on Symfony Framework.

Features:

  • PHP 8.0
  • MySQL 10.2
  • Automatic TLS certificates
  • composer-based build

View the repository on GitHub.

WooCommerce (Bedrock) for Platform.sh

WooCommerce (Bedrock) for Platform.sh

This template builds WordPress on Platform.sh using the Bedrock boilerplate by Roots with Composer. It includes WooCommerce and JetPack as dependencies, which when enabled will quickly allow you to create a store on WordPress.

Plugins and themes should be managed with Composer exclusively. The only modifications made to the standard Bedrock boilerplate have been providing database credentials and main site url parameters via environment variables. With this configuration, the database is automatically configured such that the installer will not ask you for database credentials. While Bedrock provides support to replicate this configuration in a .env file for local development, an example Lando configuration file is included as the recommendated method to do so.

WordPress is a blogging and lightweight CMS written in PHP, and Bedrock is a Composer-based WordPress boilerplate project with a slightly modified project structure and configuration protocol. WooCommerce is an open-source eCommerce platform and plugin for WordPress.

Features:

  • PHP 7.4
  • MariaDB 10.4
  • Automatic TLS certificates
  • Composer-based build

View the repository on GitHub.

WordPress (Bedrock)

WordPress (Bedrock)

This template builds WordPress on Platform.sh using the Bedrock boilerplate by Roots with Composer. Plugins and themes should be managed with Composer exclusively. The only modifications made to the standard Bedrock boilerplate have been providing database credentials and main site url parameters via environment variables. With this configuration, the database is automatically configured such that the installer will not ask you for database credentials. While Bedrock provides support to replicate this configuration in a `.env` file for local development, an example Lando configuration file is included as the recommendated method to do so.

WordPress is a blogging and lightweight CMS written in PHP, and Bedrock is a Composer-based WordPress boilerplate project with a slightly modified project structure and configuration protocol.

Features:

  • PHP 7.4
  • MariaDB 10.4
  • Automatic TLS certificates
  • Composer-based build

View the repository on GitHub.

WordPress (Composer)

WordPress (Composer)

This template builds WordPress on Platform.sh using the johnbloch/wordpress "Composer Fork" of WordPress. Plugins and themes should be managed with Composer exclusively. A custom configuration file is provided that runs on Platform.sh to automatically configure the database, so the installer will not ask you for database credentials. For local-only configuration you can use a `wp-config-local.php` file that gets excluded from Git.

WordPress is a blogging and lightweight CMS written in PHP.

Features:

  • PHP 8.1
  • MariaDB 10.4
  • Automatic TLS certificates
  • Composer-based build

View the repository on GitHub.

WordPress (Vanilla) for Platform.sh

WordPress (Vanilla) for Platform.sh

This template builds WordPress on Platform.sh, installing WordPress to a subdirectory instead of to the project root. It does not use a package management tool like Composer, and updating core, themes, and plugins should be done with care. A custom configuration file is provided that runs on Platform.sh to automatically configure the database, so the installer will not ask you for database credentials.

WordPress is a blogging and lightweight CMS written in PHP.

Features:

  • PHP 7.4
  • MariaDB 10.4
  • Automatic TLS certificates

View the repository on GitHub.


Is this page helpful?