New fortrabbit platform: features and changes

# What's new

What is new and different to the old platform?

# New core

It's an entirely new hosting platform. The infra layer is completely new.

# New dashboard

There is a new self-service dashboard, available under dash.fortrabbit.com.

# One stack

The legacy platform features two different stacks: Universal Apps (with persistent storage and direct SSH access) and Professional Apps (with ephemeral storage and horizontal scaling). For the new platform attributes from both previous stacks are combined into one. The new platform is more Uni-App-like with persistent storage and direct SSH/SFTP access.

# Environments

To better support production-staging workflows the app is now a grouping object. Dedicated hosting stacks are mapped with environments. An app is connected to the (external) Git repo, each individually scalable environment represents a branch. At least one environment, usually production, adding and removing environments is optional.

# Git deployment

fortrabbit no longer provides Git repo hosting. Connect your GitHub (other providers like GitLab and CodeBerg are planned) with the fortrabbit GitHub app to enable git push deployment instead. See the GitHub integration.

We believe this is what the majority of new users want. Our self-hosted repo didn't support PR workflows and other advanced features that GitHub and similar platforms offer. The GitHub App integration is smooth and straightforward. We've created a system to detect software, propose a build pipeline, and provide detailed deployment options. GitHub offers generous free plans with private repos. Using a third party Git provider reduces your dependence on us.

We understand that some people may have privacy concerns about GitHub, as it is owned by Microsoft. We are aware it's a big change for existing customers. Feedback on this is welcome.

Mind that using our Git deployment is not a requirement, it's optional. Direct SSH/SFTP access is always possible. This already allows integrations with other Git providers today, see the Git providers integration section.

# Build commands

The deployment pipeline is more configurable. Node.js is available during the deployment to create JavaScript bundles. See the new build commands article.

# Collaboration

Collaboration workflows have been extended. The concepts are similar, yet more flexible.

With the old platform, it was required to join the Company of the business owner to get access on their Apps. Re-inviting colleagues was not only a repetitive task, but also destroying attribution. With the new platform, the relation between the parties is more transparent.

No more company plans: Collaboration on the legacy platform is a paid feature for larger teams. All collaboration features are now available for free.

# People

We are doubling down on personal access. Each person involved should their own (free) account. This enables more scenarios and better mapping of real world business relations. See the person object article.

# Teams

Instead of a hierarchical structure with the Company as the root element, there are decoupled but related objects now. Use the new team to collaborate with a group of developers. Teams are connected to apps, developers and payment methods. See the team article.

# Payment methods

A Billing Contact is now called payment method. Like the old Billing Contact, it holds the billing credentials. Unlike before, it is not part of a Company but instead is managed by clients, individual developers and teams. A payment method pays for the apps, thus people in control of the payment method control the hosting.

# Pricing

Billing concepts mostly stay the same. There still is pro-rated post-paid billing. See price comparison for more details. Note that prices can still change during BETA.

# Components

The pricing structure, as with the former Pro Stack, is based on components. This enables you to book only required resources, avoiding over-provisioning. Presets to get started quickly are available.

# Workers and crons

Workers & crons jobs are available for all.

# Backups with restore

The new backup component offers one click restore of old states.

# New documentation

The website you are currently viewing is part of the new documentation.

# App names and IDs

Previously, the App name served as the unique identifier, test URL, and credential base. This enforced strict naming conventions and prevented renaming. The new platform separates identity from display:

• ID: Immutable unique identifier
  • Used for the test URL {{app-env-id}}.frbit.app
• Name: Display label
  • Can be changed at any time and has no format restrictions

Apps now serve as containers for environments. The app name will represent the

Vanity URLs for custom subdomains are planned, a fortrabbit branded subdomain that works like any other domain. Without having to deal with DNS entries. {{my-name}}.frbit.webhost.

# Deprecations

Which features will not be available?

# No PHP 7.4

The new platform wil only offer PHP 8 and upwards. Make sure the software you run is compatible.

# SSH keys only

Sorry, username/password is no longer an option to connect via SSH or SFTP. Please use more secure and more convenient SSH key authentication. Issues with username/password authentication have been the source of many support requests.

# No horizontal scaling

There is no horizontal scaling any more, but higher vertical scaling to cover similar workloads. To achieve this we went a long mile, but it was an important goal, the two stacks have been a barrier.

# No object storage

The new platform currently does not have S3 like asset storage. We may add it later. Larger web storage plans are available.

# No memcache

Memcache is not available for the new platform. A different key-value storage is planned.

# No Craft Copy (for now)

Craft Copy is a command line tool to speed up common tasks around Craft CMS deployment on fortrabbit craft copy all/up. It's available as a free plugin for Craft CMS. People enjoy using it. We may not port it to the new platform. Here is why:

• Craft Copy is a compatibility layer, parts are not required any more:
  • delete config files -> replace patterns
  • auto-migrate -> post deploy commands
  • Craft CMS software template
• Other parts, like db/down, might be replaced by general tooling:
  • fortrabbit agent skills
  • fortrabbit CLI
  • DDEV fortrabbit recipe
  • Improved documentation on our side
• fortrabbit does not provide a Git repo any more

We aim to be a good Craft CMS hosting provider, as compatible as possible, best without additional plugins required. Maintaining Craft Copy over the years was not always fun, for instance when a minor Craft CMS release introduced changes that required us to rethink critical parts.

Craft CMS 6 is based on Laravel. So major refactoring would be required anyway.

# No app secrets

App secrets was a feature that stored security-sensitive config — think key-value pairs in a JSON file — separately from environment variables. It wasn't that popular and caused some confusion, so it's not part of the new platform. In practice, most developers use environment variables for this anyway.

# Alternatives for app secrets

• Store secrets as environment variables. Be careful that values don't leak into logs or error output.
• Deploy a secrets file not tracked in Git via rsync or SSH as a one-off step outside the normal deploy flow.
• If your CI/CD pipeline handles deploys, inject secrets there — GitHub Actions, GitLab CI, and Bitbucket Pipelines all have built-in secret storage.
• Use a dedicated commercial secrets manager: Doppler, HashiCorp Vault, Infisical, or AWS Secrets Manager are common choices.
• Encrypt individual secret values and store them as env vars. Encrypted values are safe to expose; only the key needs protecting. We wrote about this pattern in how to keep a secret. For plain PHP use defuse/php-encryption; Laravel has this built in via the Crypt facade and php artisan env:encrypt; Symfony offers a secrets vault with php bin/console secrets:set.

# Code example

The following code example was generated by AI and not was tested.

Install the package:

composer require defuse/php-encryption

Generate a key once, save it outside of Git (e.g. a file on the server or a restricted env var):

php -r "echo \Defuse\Crypto\Key::createNewRandomKey()->saveToAsciiSafeString();"

Encrypt each secret locally and store the output (prefixed with ENC:) as an env var:

$key = \Defuse\Crypto\Key::loadFromAsciiSafeString(file_get_contents('/path/to/app.key'));
echo 'ENC:' . \Defuse\Crypto\Crypto::encrypt('my-secret-value', $key);

At bootstrap, scan env vars and decrypt any ENC: prefixed values transparently:

$key = \Defuse\Crypto\Key::loadFromAsciiSafeString(file_get_contents('/path/to/app.key'));
foreach ($_ENV as $name => $value) {
    if (str_starts_with($value, 'ENC:')) {
        $_ENV[$name] = \Defuse\Crypto\Crypto::decrypt(substr($value, 4), $key);
    }
}

# Feedback welcome

We are very open for feedback on all of this.