Platform.sh User Documentation
Edit page

Environment differences

Back to home

On this page

Try for 30 days
Flexible, version-controlled infrastructure provisioning and development-to-production workflows
Activate your trial

With Dedicated Gen 2 plans, your Production and Staging environments are on dedicated virtual machines, while your development environments run on the Grid, meaning shared redundant infrastructure. This difference means a few configuration options and tools function differently in the different environments.

This is not the case with Dedicated Gen 3 projects.

Syncing data between environments Anchor to this heading

Because of the differences between Dedicated Gen 2 and Grid Environments, data syncs aren’t available between development environments and production or staging environments. So you don’t see working buttons with those options in the Console. However, code syncs and merges are available when the code is different between a parent and child environment.

To transfer data between environments, backup your Production/Staging data and then synchronize Development data. See how to back up and transfer data.

Backups Anchor to this heading

Production environments are backed up automatically. For other environments, trigger a manual backup.

PHP Anchor to this heading

Extensions Anchor to this heading

The following table shows all of the extensions that are enabled by default in each PHP version. To add any other extension with a pre-existing package in the Debian Apt repository, open a support ticket.

Extension 5.x 7.0 7.1 7.2-7.3 7.4 8.0 8.1 8.2 8.3
amqp ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
apcu ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
apcu-bc ✅ ✅ ✅ ✅ ✅
bcmath ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
bz2 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
cgi ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
cli ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
common ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
curl ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
dba ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
dev ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
enchant ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
event ✅ ✅ ✅ ✅ ✅ ✅
fpm ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
gd ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
geoip ✅ ✅ ✅ ✅ ✅
gmp ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
igbinary ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
imagick ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
imap ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
interbase ✅ ✅ ✅ ✅ ✅ ✅
intl ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
json ✅ ✅ ✅ ✅ ✅ ✅ ✅
ldap ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
mailparse ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
mbstring ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
mcrypt ✅ ✅
memcached ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
mongodb ✅ ✅ ✅ ✅ ✅
msgpack ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
mysql ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
oauth ✅ ✅ ✅ ✅ ✅ ✅ ✅
odbc ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
opcache ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
openswoole ✅ ✅
pdo-sqlsrv ✅ ✅ ✅ ✅
pgsql ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
phpdbg ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
pspell ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
readline ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
recode ✅ ✅ ✅
redis ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
snmp ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
soap ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
sodium ✅ ✅ ✅ ✅ ✅ ✅ ✅
sqlite3 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
sqlsrv ✅ ✅ ✅ ✅ ✅ ✅ ✅
ssh2 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
swoole ✅ ✅
sybase ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
tideways-xhprof ✅ ✅ ✅ ✅ ✅ ✅
tidy ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
twig ✅
uuid ✅ ✅ ✅ ✅ ✅ ✅
xcache ✅
xdebug ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
xml ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
xmlrpc ✅ ✅ ✅ ✅
xsl ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
zbarcode ✅ ✅ ✅
zip ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
zts ✅ ✅ ✅ ✅ ✅

Configuration options Anchor to this heading

If your project doesn’t support PHP configuration through a php.ini file, you can still change all PHP options that can be changed at runtime. For example, change the memory limit using ini_set('memory_limit','1024M');.

For other PHP options, such as the following, open a support ticket:

  • max_execution_time
  • max_input_time
  • max_input_vars
  • memory_limit
  • post_max_size
  • request_order
  • upload_max_filesize

Xdebug Anchor to this heading

All Dedicated Gen 2 clusters that have Xdebug enabled have a second PHP-FPM process. This second process is used only when requests include the correct Xdebug key in a header.

So you can keep Xdebug always on and not worry about performance issues as it’s ignored on most requests.

To obtain the Xdebug key:

  1. Open a support ticket.
  1. Set that key in the Xdebug helper for your browser. Whenever you have Xdebug enabled, the request uses the alternate development PHP-FPM process with Xdebug.

Solr Anchor to this heading

On Grid environments, Solr runs as a standalone instance. On Dedicated Gen 2 Environments, it runs as SolrCloud: a cluster of Solr servers to ensure high availability. This shouldn’t affect you most of the time, but may influence certain advanced use cases.

Cron tasks interrupted by deploys Anchor to this heading

How cron tasks interact with deploys changes based on the environment.

On Grid environments, a running cron task blocks a deploy until the cron is complete. On Dedicated Gen 2 environments, a deploy terminates a running cron task.

Specifically, when a deploy to either Production or Staging begins, any active cron tasks are sent a SIGTERM message so that they can terminate gracefully. If they’re still running 2 seconds later, a SIGKILL message is sent to forcibly terminate the process.

So it’s best to ensure your cron tasks can receive a SIGTERM message and terminate gracefully.

Configuration & change management Anchor to this heading

You can’t manage some configuration settings via YAML configuration files on Dedicated Gen 2 Environments. In these cases, you need to open a support ticket. You can have some settings different between staging and production environments. It’s assumed you want the settings the same, unless you state otherwise in the ticket.

The following settings require a support ticket:

Logs Anchor to this heading

Dedicated Gen 2 Environments have a slightly different location for container logs. The difference shouldn’t be noticeable if you use the CLI.

Is this page helpful?