Permission denied (publickey)¶
SymfonyCloud leverages the SSH protocol to access running containers and Git over SSH for project deployments.
They are four possible reasons to why you might encounter this error:
Your public key has not been uploaded to SymfonyCloud. Check that your SSH key is properly uploaded using
symfony account:ssh:keys. If your key is not present (or if you are not sure) use
symfony account:ssh:key:addto upload it.
Please note that SymfonyCloud and SymfonyConnect SSH keys are currently differentiated: even if you previously uploaded your key to SymfonyConnect, you have to reupload it using the command mentioned above.
SSH keys propagation can take some time and you’ve been too fast. Try again to use
symfony env:deployafter a couple of minutes and it should work.
You’ve been recently added to a new project (only impacts
symfony ssh): after adding new users to a project, a new deployment or a redeployment is required before the new users can access the project. If no deployment occurred since you’ve been granted access to the project, use
symfony env:redeploy, wait for the end of the deployment and try again to access the project (this must be done for every environment).
You are using Windows.
symfony ssh, the SymfonyCloud client will make its best to use PuTTY registered SSH keys (connecting to Pageant) and OpenSSH keys saved in
$HOME/.ssh(mimicking Unix). You can use
symfony ssh -vvvto debug which keys are loaded by the SymfonyCloud client.
symfony deploy, some work is handed of to Git and the details then depends on your setup. We recommend you to use the following snippet to debug your issue:
1 2 3
set GIT_SSH_COMMAND=ssh -vvv set GIT_TRACE=2 git ls-remote [email protected]:test.git
Host key verification failed¶
This issue usually happens only on Windows
As for SSH authentication, on Windows, SymfonyCloud uses both PuTTY and OpenSSH
directories for SSH host key verification, but
symfony deploy is based on
Git which is not using the same process. If you encounter this error message
you can use
git ls-remote email@example.com:test.git to trigger a new
connection and force Git to register the key.
Unsupported key type¶
SymfonyCloud leverages the SSH protocol to access running containers and Git over SSH for project deployments and might have to read your SSH keys to do so.
This error can happen in a very specific situation if the two following conditions are met:
- Your key is stored in the OpenSSH format; as opposed to the PEM format (in
this case, the first line will look like
-----BEGIN OPENSSH PRIVATE KEY-----)
- Your key uses the DSA or ECDSA algorithm (
ssh-keygen -l -f <file>will tell you which algorithm is in use)
This use case is not yet supported by the upstream library we use. In the meantime you have two solutions:
Run an SSH agent and load your key using
Convert your private key back to PEM format:
ssh-keygen -p -m pem -f <file>
This command upgrade your key inline. Please do a backup before!
DSA keys are considered insecure and ECDSA security assessment depends on your computer ability to generate good random numbers. So alternatively to the two solutions mentioned before, you can also migrate to the Ed25519 algorithm but keep in mind this might require quite some work from you as you will end up with a new public key to deploy everywhere.
Environment variable not found (during the build step)¶
SymfonyCloud leverages Symfony Runtime Environment Variables defining services connection information via environment variables (read the Connecting to a service from the services documentation for more information).
Additionally, to make containers reusable from one environment to another and to make (re-)deployments faster, the build step has no services started. Therefore the environment variables to connect to services are not available during the build step.
It might happen that an application build breaks because of an environment variable that does not exist:
Found 1 new commit Building application 'myapp' (runtime type: php:7.3, tree: abcd123) Generating runtime configuration. Executing build hook... [...] W: Generating optimized autoload files W: > Incenteev\ParameterHandler\ScriptHandler::buildParameters Creating the "app/config/parameters.yml" file W: > Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::buildBootstrap W: > Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache In EnvVarProcessor.php line 76: Environment variable not found: "DATABASE_URL". W: Script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache W: handling the symfony-scripts event terminated with an exception W: W: W: [RuntimeException] W: An error occurred when executing the "'cache:clear --no-warmup'" command: W: W: W: W: W: In EnvVarProcessor.php line 76: W: W: Environment variable not found: "DATABASE_URL". W: W: W: install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] W: [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] W: [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] W: [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] W: [--] [<packages>]... W: E: Error building project: The build hook failed with status code 1. Aborted build. E: Error: Unable to build application, aborting.
This usually happens with applications migrated from Symfony pre 3.2 to 3.2 and
upper. When migrating, one needs not to forget to define defaults in the
.env file or in the service container configuration:
# .env DATABASE_URL="mysql://db_user:[email protected]:3306/db_name"
1 2 3
# config/services.yaml parameters: env(DATABASE_URL): "mysql://db_user:[email protected]:3306/db_name"
1 2 3 4 5 6 7 8 9 10
<!-- config/services.xml --> <?xml version="1.0" encoding="UTF-8" ?> <container xmlns="http://symfony.com/schema/dic/services" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://symfony.com/schema/dic/services https://symfony.com/schema/dic/services/services-1.0.xsd"> <parameters> <parameter key="env(DATABASE_URL)">mysql://db_user:[email protected]:3306/db_name</parameter> </parameters> </container>
// config/services.php $container->setParameter('env(DATABASE_URL)', 'mysql://db_user:[email protected]:3306/db_name');
Symfony applications created before November 2018 had a slightly different
system, involving a
.env.dist file. For information about upgrading, see:
Nov 2018 Changes to .env & How to Update.
SQLSTATE[HY000]  Connection refused (during the build step)¶
This error message is usually due to a known Doctrine bug/limitation.
Some parts of Doctrine configuration (such as Entities metadata build) need to know the exact database version to be built. This is usually done during Symfony cache warmup for more efficiency but this requires the database to be available, which is not is the case on SymfonyCloud.
One can reproduce this issue locally by shutting down their database and try clearing Symfony cache.
The best long-term solution to this problem is to make sure no connection to the database is done during Symfony cache warmup. However, this solution might require to fix some third-party code or not be possible at all.
In this case, the best workaround to date is to explicitly tell Doctrine which
database platform and version the application is going to use. This can be done
either by updating the default
DATABASE_URL in the
.env file by
?serverVersion= and the targeted version or by updating the
Doctrine semantic configuration under the keys
1 2 3 4
# .env ###> doctrine/doctrine-bundle ### DATABASE_URL=mysql://db_user:[email protected]:3306/db_name?serverVersion=10.2.0 ###< doctrine/doctrine-bundle ###
1 2 3 4 5
# config/packages/doctrine.yaml doctrine: dbal: driver: pdo_mysql server_version: '10.2.0'
Don’t forget to keep this value in sync with the version configured in
This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.