Understanding the platform¶
We claim that the fortrabbit hosting platform is different to classical hosting. Our comparison pages give you a good picture what fortrabbit is about:
The App Concept¶
# simplified App topology ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃App ┃ ┃ ┏━━━━━━━━━━━━━━━┓ ┏━━━━━━━━━━━━━┓ ┏━━━━━━━━━━━━━┓ ┃ ┃ ┃ ┃ ┃Webserver ┃ ┃Database ┃ ┃ ┃ ┃ ┣─┫& PHP ┣─┫cluster ┃ ┃ ┃ ┃ ┃ ┃ ┃ ┃ ┃ ┃ ┃ ┃Load Balancer ┃ ┗━━━━━━┳━━━━━━┛ ┗━━━━━━┳━━━━━━┛ ┃ ┃ ┃ ┃ ┏━━━━━━┻━━━━━━┓ ┏━━━━━━┻━━━━━━┓ ┃ ┃ ┃ ┃ ┃Webserver ┃ ┃Database ┃ ┃ ┃ ┃ ┣─┫& PHP ┣─┫cluster ┃ ┃ ┃ ┃ ┃ ┃ ┃ ┃ ┃ ┃ ┃ ┗━━━━━━━━━━━━━━━┛ ┗━━━━━━━━━━━━━┛ ┗━━━━━━━━━━━━━┛ ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
An App is a virtual container for your web project, website, web application, staging branch, project or whatever you do.
Multiple Apps per Company¶
fortrabbit hosting has a multi-seat and multi-tenant model. Apps are owned by Companies (your business) and managed by Accounts (you). The App plans displayed on the pricing page are per App. You can create as many Apps as you want of course.
One website per App¶
With classical server hosting you rent out a machine to host multiple websites. While this seems to make economic sense — it's not smart. Just think about these scenarios:
- "website A" needs runtime version y, while "website B" requires an version x
- "website C" has a nasty bug and crashes the whole server
- "website D" has a security vulnerability, the whole server get's hacked
- "website E" get's popular and receives lot's of traffic, slowing other websites down
- Your fellow web developer colleague "accidentally" removed all files on the server
Apps are better:
- Apps start a friction of a server but can be scaled across multiple servers
- Each App has it's own settings
- Apps are isolated from each other
So, a fortrabbit App is designed to host one website:
- There is only one MySQL database per App
- Each App has only one Git repo
- Each App has it's own collaboration rules
- Each App has it's own performance metrics
Two App types¶
fortrabbit comes in two flavors (stacks): Universal & Professional. With each App you create, you can choose between either one. This can't be changed later on. The two Stacks are different from each other. The rule of thumb is: When unsure, choose Universal. Learn more here:
- About the Stacks
- About Universal Apps and what is unique about them
- About Professional Apps and what is unique about them
The following sections here are describing functionalities that are shared by the two different stacks.
Each App comes with a set of basic features and limits.
- a dedicated Git repo
- a unique App URL
- custom metrics
- included monthly traffic
- various settings in the Dashboard
- collaboration options
Most of it can be viewed and edited in the Dashboard.
There are various settings to control the routing of domains. Please also see the domains help article.
While creating your fortrabbit App you will be asked for an App name. This name can't be changed later on and is used in many places as an identifier. The most prominent one is your default App URL which looks like this:
https://your-app.frb.io/. This is where you can always reach your App thru the web browser. Use the App URL for development, testing and to connect to external services.
Please mind that you can not change the App name later on. 7 days after you have deleted an App, the same App name will become available to use again.
Sending transactional mails from your App URL
Some clients asked how to setup TXT records for App URLs. They have the idea of sending mails over a transactional mail service from the App URL, for testing or even for production.
And it is probably not what you want. At the end of the day, you want your mails to be sent from own domain. transactional mail providers need to take extra care that you are not a spammer, as they give very powerful tools. our generic App URLs do NOT look good from their point of view. For the App URL there isn't an MX record. So that sub-domain looks suspicious to any mail-server.
We are using postmark app. It should work the same as mailgun or any other transactional mail provider. We have configured and verified our prime domain to be used with the service. Now, our dev and staging environments are also using the "real thing", but is configured (in our code base) so that they are sending all mails to "firstname.lastname@example.org" (instead of what is entered by the testers).
How other users are testing mails: some clients are using mailtrap to test mails. I have no experience. but as far as I know, it's easy to setup and use.
Set up a custom domain¶
You can register your App to accept requests from any external domain you route to fortrabbit — see also the domain article. To set up a domain routing, you add a new custom domain within your Apps domain settings in the Dashboard.
Per default all the domains of the App will route to the same root path (sometimes this is also called: document root, docroot or root folder):
htdocs. This path is, where the first
index.php will be called, when people are visiting your App on any domain.
This path setting can vary, depending on what the framework or CMS you have selected in the software chooser when creating the App:
|Laravel, Phalcon, Craft CMS||htdocs/public|
|Drupal 8, WordPress, Grav||htdocs|
You can however set the root path afterwards at any given time by visiting the according setting in the Dashboard under your App.
Individual root paths per domain¶
In some cases, you might want to route individual domains to different folders. Please mind that there are limited use cases for this and don't use one App to host multiple website (see above as well).
When visiting the root path settings form with a Professional stack Apps you will find a switch to change from a global root path for all domains to custom root paths for each domain. Mind that you can also use
.htaccess files with
RewriteRule directives to handle different domains differently.
Most connections calls on most ports are forbidden for security reasons. You can request to white-list a port or port range. With the firewall setting of your App you can see custom white-listed ports and request a new firewall rule.
Each App comes with "Usage metrics": Those show you the current status of the Web storage, MySQL storage and Object Storage and context of your
Some Apps also come with "Performance metrics": Those show you how fast your App is and where you might need to improve. Performance metrics are: requests, PHP response time, traffic, errors and other useful stuff. You can set different time intervals to monitor performance over time.
The team settings of the App are showing you which other developers have access to the App. From here you can also invite new team members directly to the App.
See our collaboration article to learn more about joint development.
This setting links to the Company owning the App. From here you can also:
Changing App ownership¶
- Go to the App in the Dashboard
- Click the "Change ownership" button
- Choose a different Company (and Billing Contact)
Change ownership button, linked from your App overview is a very powerful tool. You can move the App to a different Company or Billing Contact you have access to. That means, you can assign the App to a different team, and or to be billed from a different Billing Contact.
This action can only be done by Accounts who have Owner or Admin privileges on at least two Companies or one Company with two Billing Contacts. In other words, you need to have something first, to change it to. Also the App must be paid, not in trial mode.
The App will be billed on the old Billing Contact until that day of change and from the next day on to the new Billing Contact. For example: If you move your App on the 15ths of a month to the Billing Contact of another Company, it will be billed until the 15ths to the old Billing Contact and starting from the 16ths to the new Billing Contact.
Inviting a client to take over an App¶
Are you working on behalf of someone? You want your client or the boss of the agency to pay for hosting? Here you can start the invitation. See our client collaboration article for more details.
The App trial¶
You can test fortrabbit for free. Therefore each Account can have one trial App running. The purpose of the trial is test-drive the platform. See if it works as advertised. See if fortrabbit is the right hosting solution for you.
Starting a new trial App¶
Find the "Create an App" on the Dashboard home. When asked for the plan, you can choose the free trial option instead. Trial Apps are available for both stacks, Universal & Professional.
The trial App scaling specs are matching a small preset, always enough to get started. The trial is NOT a forever-free tier. An urgent limitation is, that the trial has a limited lifetime:
Extending the trial¶
The default trial time is short. A timer in the Dashboard with your App will show you the time left. You can extend the evaluation period by completing some simple tasks like:
- Confirming your Accounts e-mail address
- Setting your real name under your Account
- Deploying some code to the trial App
- Routing a domain to the trial App
A task that is completed has a check-mark
✔. Tasks that are still todo will show how much time you will gain more time.
Additionally, after some trial time has passed, we show a link to a contact form where you can ask us to extend the trial time. Here you'll write us something about your goals with the trial and we are happy to extend the trial for much longer period. You can see those tasks in the Dashboard with the overview of your App.
Upgrading the trial¶
You can, of course, upgrade from your trial to a paid plan at any time. You can do so under your Apps overview.
The end of a trial¶
When the trial is finally over, the trial App will be deleted — we will not keep your data hostage. Good news is: we will inform you by e-mail before it happens and you can start a new trial right away, after your current trial ended.
Now you know the basics about Apps on fortrabbit, keep going: