By Bruno Skvorc

PHP as a Service – Fortrabbit

By Bruno Skvorc

PaaS (platform as a service) is not a new concept. The fact of the matter is hosting companies have long since provided PaaS when they sell shared-hosting services that include PHP on the shared server. This is fundamentally different, however, from how a PaaS business works.

In this article, we’ll take a look at a newcomer to the platform service provider arena – Fortrabbit – and set up a simple PHP/MySQL application that can be publicly accessed in a matter of minutes.

Basic knowledge of the LAMP stack is assumed, and you also need to have a basic grasp of Git (if you don’t here’s a decent introduction), and you need to have SSH keys generated and ready for use (if you don’t, refer to this resource from GitHub). This walk-through is Unix oriented (so OS X and Linux users are fine), but it can also be applied to a Windows environment with minor changes.

Fortrabbit – the Who, Why, and How

Fortrabbit is a young PaaS company who say the hosting business is broken, and too much about price dumping and too little about quality. In order to fix the problem, they made a PHP-exclusive business that caters to developers’ most common needs. Their hosting plans are accessibly-tiered for everyone, from hobbyists (free plans) to enterprises (high-availability upgrades are available at the click of a button).

With a single dashboard, you have an overview of all your applications, regardless of your role in them.

Applications can be made publicly visible whenever you choose to deploy, so you can easily demonstrate what you’re building to your clients whenever you want. Once an application is complete, you can transfer ownership to the client, who then becomes in charge of payments from that point onward. You can even retain a “Project Manager” role on the application to be able to perform future fixes and upgrades. The whole freelancing process is literally streamlined into minutes.

Deploying works with Git, SSH, SFTP, ReSync, and Composer. You have full SSH access to your application and can play around with it however you see fit. Frameworks and content management systems are supported and easily installable out of the box, and Phalcon support is coming soon now available too (version 0.9)!

The demo app

Let’s get a simple Hello World application up and running. Clone the example repository from Github. It’s nothing but a simple CodeIgniter skeleton application, slightly modified for our purposes here. The controller reads the URL input to find an ID parameter, and if it finds none, it sets it to 1, otherwise, it uses the one provided. This ID parameter dictates which database row we fetch, and thus whether the output will print “Hello World” or “Hello Bruno”.

See the db directory for the SQL import script create a database called “sitepoint”. Also, modify the database.php file in the application/config directory accordingly so your app can access the database. In my case, the username is root, and I have no password.

Test the application by creating a virtual host for it. For the sake of example, let’s assume you named the host fortrabbit.sitepoint.test. Thus, entering fortrabbit.sitepoint.test/ into your browser should say “Hello World!” and fortrabbit.sitepoint.test/welcome/index/id/2 should say “Hello Bruno!”. All good? Great! Let’s cloud it up.

Setting up a Fortrabbit Application

Go to Fortrabbit and sign up for an account. Once you have an account, proceed to click the New App button on the dashboard:

Select the Bootstrap Free plan on the next screen and click Purchase. Note the “freeze” limitation – after a certain amount of inactivity, you app will become frozen and unavailable and you’ll have to log back in to “thaw” it. This is to both conserve resources and prevent users from hogging their services without paying. Consider it an unlimited free trial.

On the next screen, enter an app name and your public SSH key. We’ll need this to push our app live. See the following figure for reference.

You’ll have to wait for the setup to complete on the next screen, and a couple of minutes later for your app to be ready. You’ll receive an email with all the necessary credentials and URLs to manage and visit your application. In fact, visiting the Test URL from the email/final configuration screen will produce a screen not unlike this one:

A full report of the stack you’re running is shown, a working application ready to be turned into something useful.



The app dashboard Fortrabbit takes you to after you click “Take me to my app” on the final configuration screen is where proper management takes place. Here you can see how much time you have until the app is frozen, and can reset the timer at will. All you do by doing that is prove your activity and the app stays alive, simple as that. The strength and cost of your app’s plan are defined here as well, along with some quick stats and a list of purchased add-ons (e.g. Memcache is an add-on you need to pay extra for).

The stats tab will give you a detailed overview of your app’s performance, and the Git tab lets you revisit the public SSH key input from the initial configuration.The SSH/SFTP tab simply lists access credentials.

The PHP tab lets you set some configuration directives and PHP options and the domains tab provides an easy access to defining new domains and subdomains so you can have a custom domain point to your application and get rid of the long eu.frbit suffix. There is also the permissions tab which lets you define a new owner for the application for the purposes of a transfer, add team members, and more (the free bootstrap plan only supports a one-man operation though).


Fortrabbit, being young, still does’t have a web GUI for MySQL installed, so no PHPMyAdmin. You can, of course, install your own – but there’s another option that’s quite practical. MySQL Workbench supports remote tunnel connections via SSH, so assuming you have it installed (and you really should have it installed), open a new connection and define all the required parameters:

Now you have access to your remote database via a local client – and editing the database could not be easier. Since the Fortrabbit MySQL user/pass combo is different from our local setup, we need a way to accommodate this without having to constantly update the database configuration. Luckily there’s an easy way to do this as well. At the end of application/config/database.php, we placed the following code (replace your username and password accordingly):

<!--?php <br ?-->if (isset($_SERVER['APP_NAME'])) {
    // This means we're on Fortrabbit, and need different credentials.
    // Local setups don't have the "APP_NAME" environment variable
    $db['default']['hostname'] = '';
    $db['default']['username'] = 'sitepoint';
    $db['default']['password'] = 'xxxxxxxx';

This works because Fortrabbit defines an environment variable for every app called APP_NAME which we don’t have on our local machine. Whenever we’re testing locally, our app accesses the local database as it did before. When we test online, the username, password, and host switch to the Fortrabbit credentials. Note that you can define an arbitrary amount of environment variables in the app’s dashboard under the PHP tab.

The next step is importing the SQL file into the database. With our connection to MySQL still open, import the provided SQL file from the db folder.

Now let’s finally deploy our application. This is done in several steps and has multiple possible approaches; we’ll cover only one.

Step 1: Clone your current Fortrabbit app

In the terminal, enter git clone which will clone an empty repository from your Fortrabbit app. It might be strange that the repo is empty when in fact you see some content when you visit the app’s URL, but this is because there’s a hidden index.php file inside it already that’s initially ignored. As soon as you push the first commit, this index.php file is overwritten (if you added such a file in the root of your project, that is).

Step 2: Add content to folder, add to Git

Next, we take the entire content of our local application and just move it into this directory. Then add the contents of the directory to the repository with the following command: git add *, and of course, make a commit (git commit -am 'Initial commit')

Step 3: Push the app live

Use the git push origin master command to push your application live. The origin master part is only required on first push – subsequent pushes do not require it.

Step 4: Change the domain setting

In the “Manage app” screen under the domains tab, add public after the original URL in the input field, like so:

This is so the server looks for the application root inside public, instead of the unavailable top folder.

That’s it! Visit your app now via its URL and you should see it work just as it does locally. Append the URL part with the parameters (/welcome/index/id/2) and see the string change. This shows us that both URL rewriting and the database connection work as they should.

Free Give Away

In a sea of *aaS services, Fortrabbit stands out with usability, simplicity, approachability and a heavily involved staff that are there for you every step of the way. In this generous and ambitious spirit, Fortrabbit is teaming up with SitePoint for an awesome give away!

Five lucky readers will win coupon codes worth 100€ redeemable for Fortrabbit service. To be eligible, 1) try out Fortrabbit and post a comment below letting us know your experiences, or 2) follow @phpmasterdotcom and share this article on Twitter with the hashtag #phpmaster, all by February 20th. Five winners will be chosen at random shortly thereafter. Comment winners will be notified by email (be sure to provide a valid email address in the contact-form!) and Twitter winners by direct-message.

Good luck!

  • Thanks for the review.
    btw: PhalconPHP 0.9.0 (web framework as a C extension) is supported now.

    • Thanks for the heads up, that’s fantastic news! I’ll update the article as necessary!

      • Antonio

        amazing! thanks

  • Looks promising. Will give it a try.

  • Huy

    Is this for EU people only?

    • Nope, it’s available globally

    • the current datacenter location is AWS/ireland.
      europeans have the lowest latency. just deploy you App and check if it feels okay from your location.
      from US or Asia response time is about 100ms slower than from EU.

  • Rajiv Seelam

    I have tried fortrabbit. It was so easy! Then read reviews of other “famous” platforms like phpfog and pagodabox.. But, eventually went back to fortrabbit! It’s so easy! They give good support and moreover, It’s like I have my own server administration team. :)

  • Dom

    Can hardly wait to start. So missing PHPfog :-(

  • Nils

    to use fortrabbit is like using ecological correct ingredients: it’s not cheap but it taste better.

  • The first paragraph says:
    PaaS (platform as a service) is not a new concept. The fact of the matter is hosting companies have long since provided PaaS when they sell shared-hosting services that include PHP on the shared server. This is fundamentally different, however, from how a PaaS business works.

    But reading the article, I don’t see how it is any different to a standard hosting a/c. The only difference I can see really is that you seem to be restricted to PHP & MySQL. Maybe I missed it, could someone explain the difference for me?



    • On shared hosting, everyone is running off a single instance of PHP. PHP was loaded, and everyone’s app is interpreted through that one interpreter. This means the PHP is often severely outdated because some people might be running their websites on PHP 5.1 code which has some features that have been deprecated in 5.4. Updating just for you would break their apps. On Fortrabbit, you get your own instance of PHP per app with several addons you can activate – there’s no trouble with installation or compiling from source, all you need to do is just flip a switch in your app’s control panel. Fortrabbit also makes sure to keep your version of PHP up to date, so your version and the changes you make on it does not affect anyone else. Essentially, it’s almost like a virtual private server without sudo access. A server on which you actually have people who manage it – you basically get your own server administrator, in a way.

  • Hi,

    Nice interface! It would be pretty straightforward to make this site accessible. I see you’ve written your app in html5 and have some roles in there so good effort so far. I suggest adding accesskeys, skiplinks and make the App Creation console use ARIA live regions so screenreaders can relate what’s going on inside it.



  • @Dave
    Great question. In traditional shared hosting you share a “box” with hundreds of other clients – that’s why they can offer the services for a very low price. If FTP is your prefered way of “deploying” and you site gets up to 1000 hits per day, it’s fine.
    But if want to use Git, Composer, Hooks or SSH for your deployment, your App requires the latest PHP version or some fancy extensions or high availability, (our) platform is the way to go. This kind of managed setup was very expensive in the past – PaaS changed that. You are right: Public clouds also rely on shared components, but the architecture provides isolated resources and the ability to scale within seconds.

    organic food for healthy developers.

    @William Parry
    thanks for your suggestions. we will try to make the interface more accessible.

  • Attila Fulop

    Looks very promising! I’m particularly interested in PhalconPHP.

    Can the 1 node variants with 2-4 processes come up with a fair user experience? Compared to the vserver plan I’m having today, it seems to be quite under-powered for the double-triple price. I know the two are not the same thing but from my (and my customers) perspective, both serve the same purpose. I might be completely wrong so please let me know any benefit I’m not paying attention to.

    • fortrabbit

      Hi Attila,
      We are also fans of PhalconPHP, because it’s a modern framework with a small footprint. Hope to see more addoption in the future.
      You can not compare a managed platform like ours with VPS. If you are able to setup and maintain your own servers and if you don’t calculate the hours of your sysOp tasks, unmanaged VPS is cheaper and more powerful.

      If you are curious about the performance of the paid plans – give it a try, run your benchmarks & scale – we have a daily billig period, it starts at 0.50 €/day.

      • Attila Fulop

        Thanks for the reply. Yes, you’re right vps’s are not fully managed and that’s a big difference. For me the most attractive features in your service are those targeted to developers, eg. deploy via git. (Bazaar and/or Mercurial support would be an immediate go.)
        The painless scalability is also seductive.

        Keep me bombed with offers, I’m likely to switch one day :D

  • It’s interesting, but I’m not sure it’s competitive on price. The basic plans have an unchangable robots.txt that block search engines, so to actually run anything public you’re looking at a minimum of €15+VAT/month. I can get a cloud VPS from my current host for less than that, with more storage and traffic, and full ssh access

  • Attila Fulop

    A marginal question: While benchmarking today I found that replacing the sfYaml component to php-yaml results in 70% speed gain. The latter is a C Library wrapper thus the huge speed difference. It involves having the appropriate php module installed. What is fortrabbit’s policy on that? Do you install many php extensions, or just a certain subset of them?

    • fortrabbit

      Which extensions are you missing?

      There is a simple policy. We will extend the list if:
      1) The extension has no conflicts with your current environment
      2) The extension is actively maintained
      3) The extension is requested more than one time :-)

      • Attila Fulop

        The extension is among the basic php extensions, but I guess it’s one of those usually not enabled:

        That policy on extensions sounds quite good for me. +1 for that ;)

  • Doron Gutman

    I’ve been trying for the past year various PaaS solutions such as phpcloud, phpfog (RIP), and fortrabbit. So far, my experience with fortrabbit has been the best.
    Composer support, convenient control over extensions status, and their support team (which quickly fixed it when composer was yelling) are the main reasons I haven’t abandoned it yet.

    I think the main missing feature is a library of 3rd party solutions for items such as mongo hosting, smtp providers, etc.. with an easy-to-connect option, such as what phpfog had.

    Awesome product, fortrabbit team!

  • I’ve played around with their service and really like what I see so far. Will definitely use them again for my next real project.

  • John Madrak

    Fortrabbit has been an awesome experience so far! The support staff have been responding to my emails faster than any other provider I’ve worked with before, and they have been willing to customize my environment to fit some of our unique needs (such as opening a variety of ports). They’ve even made suggestions for upgrading certain components of our infrastructure for stability/uptime enhancements.

    Outside of their support, the experience has also been excellent overall. I’ve uploaded a few projects and just recently moved a production environment over to them as well, and so far no complaints. The sites are quick to respond and there have been no outages.

    Finally, the user control panel has given us the ability to easily assign developers to projects and allow them to work freely in those environments. We’ve been able to start creating a workflow based around using fortrabbit’s services and so far it has greatly impressed us with how it has affected our work.

    Hats off to fortrabbit for providing an excellent service. I’m excited to see what’s to come.

  • I found Fortrabbit very recently and have been using it to develop the backend of my Android app. I’m very happy with it thus far.

  • So I signed up for this service and on the surface it looks really good. I intend to use it for some API stuff I am doing with Laravel. However I found the freeze thing to be a bit annoying, a 48 hour grace period and then a freeze is a bit much. I can take a week but having to log in every 48 hours to click on a button tends to be slightly off putting (for me anyway).

    • Uzo

      I’m sure using their resources and service without paying is slightly off-putting (for them, that is).

  • I am using fortrabin. Its great no doubt, but we can use only one mysql database at a time with current app.

  • im using fortrabin thats really good! and the app is alsome good!

Get the latest in PHP, once a week, for free.