Quirks & constraints

Service scope¶

Apps are lightweight containers optimized for speedy web delivery of PHP applications. Apps are specialized to do just that. Apps are single-purpose by design. Apps are also managed, they offer a jailed SSH environment for security reasons.

Therefore, it's NOT possible install things like: FFmpeg, Node, jpegoptim, optipng, Gulp, webpack or Rails. Sounds scary? Embrace the idea of decoupled services, don't let your users wait, while your application is crunching a video.

• Learn more about Apps

Service location¶

Data center locations are available in Ireland (AWS EU-1) and Virginia / USA (AWS US-EAST-1). Data center can be chosen for each App indidually, but can't be changed later on. The service is available in Euro (€) or US Dollars ($) this can be chosen with each Billing Contact. The fortrabbit headquarter is based in Berlin, time zone is: CET.

Mailing¶

Sendmail — the Mail Transfer Agent — is not available on fortrabbit.

In PHP Sendmail is usually used with the mail() function. Back in the good 'ol days, this would simply call the shell command sendmail from the shell to send a mail directly from the web server to the receiving mail server.

In recent days, this is a really bad practice: your web server can send mails, but not receive any - it is not a mail server. So it is not distinguishable from any home PC part of a bot net. Long story short: it is very likely that your mail will not be received.

Direct SMTP¶

Instead of sendmail you can use a mail script that uses SMTP (Simple Mail Transfer Protocol) with your e-mail provider - usually the one that provides your domain - directly.

Transactional mail services (see extending fortrabbit) can actually do the bulk mailing for you. You can either connect to them via "SMTP relay" or by "API". Those services help you to save your Apps resources, are probably more reliable and have some nice extra features like analytics.

In the following we focus on an SMTP implementation. There are countless possibilities how to do this. Most frameworks and CMS give them to you out of the box. If you use a custom script, have a look at Swift Mailer.

There are special solutions for WordPress, Laravel & Symfony.

PHP¶

PATH_INFO¶

Our runtime implements PHP via FastCGI + FPM. To utilize PATH_INFO you need to do a small hack-around in your .htaccess file:

RewriteCond %{REQUEST_URI} \.php/ [NC]
RewriteRule ^(.+)\.php/(.+)$    /$1.php [NC,L,QSA,E=PATH_INFO:/$2]

Basic authentication¶

If you want to use HTTP basic authentication, you need to forward the Authorization header via an .htaccess directive and parse the contents manually.

Authorization header¶

If you need the Authorization header, for OAuth for example, you have to forward the header explicitly via an ENV variable:

RewriteCond %{HTTP:Authorization} .
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

pecl_http¶

The PHP extension HTTP from PECL is enabled by default. The classes HttpRequest, HttpRsponse and HttpMessage are very handy replacement for curl and alike. The downside: it breaks CakePHP in some cases. You can disable the extension in your Settings -> Extensions tab of your App.

Available locales¶

Git¶

Branch name matters¶

You can use / create as many branches as you want and push them to the fortrabbit remote repository. However there are only two branches which will be deployed: the master branch and a branch which has the same name as your App. If your App is named your-app then a branch named your-app will be prefered over the master branch.

This is a feature, not a bug: use other branches as "transport" branches to interchange code with other developers / locations without publishing it to your web space. Once your code is ready to deploy, just merge it in the master (or your Apps name like: {{app-name}}) branch and push it.

Release package limit¶

To keep deployment fast for everyone the size of the release package is limited to 200 MB. Read on.

MySQL with persistent connections during upgrade¶

When scaling (up or down) your MySQL, your App's database will be migrated to a new node. Therefore the CNAME target of your Apps MySQL hostname will be changed. The hostname's time to live (TTL) is 60 seconds, which reflects the maximum expected downtime during upgrade.

With persistent connections this can take longer (possibly up to half an hour). Thefore we recommend to disable persistent connections during upgrades and downgrades.

Firewalling¶

Outgoing traffic is limited for security reasons — most ports for making outgoing calls are locked. Only the most standard ports are white-listed. Any access to service Components provided by us directly (Memcached, MySQL, ..) is of course also allowed. Any other traffic is denied - but you can request to open ports for your App. To do so: login to the Dashboard, browse to your App, go to the firewall settings, "request a custom white listing".

Outgoing IP¶

In some cases you need to know your Apps IP address, like for payment processing or with fire-walling in corporate environments.

For Professional Apps the outgoing IP is fix, for each region (EU, US …). Please dig your Apps IP. For Universal Apps the IP is not guaranteed. Although with high probability, it won't change during the Apps lifetime.

You can setup a regular running "test", which queries https://ifconfig.co/ or the like to notify you on changes. Querying such a service from your App eg <?php echo file_get_contents("https://ifconfig.co/"); is the easiest way to determine your Apps current IP. Depending on the use-case, it is possible to use a HTTP proxy provider like QuoteGuard for a vanity IP address. There is also a semi-official list of AWS IP ranges.

What this isn't¶

Embrace the idea of decoupled services! We don't offer some classical hosting providers standards such as:

• Plesk, cPanel, ISPconfig, any classical hosting control panel
• eMail hosting, E-Mail address configuration
• any WebMail, so no RoundCube or SquirrelMail
• Domain ordering, top level domain registration services
• pre-installed phpMyAdmin, phpBB, Wikis …
• one-click installers

Our advice to you, the professional developer: consider to abandon your all-in-one old school hosting.