What's new on the fortrabbit platform

# 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 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.

Git deployment is optional. SSH and SFTP access work for every app, and other Git providers can deploy through them, see Git providers.

# 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.

Collaboration was a paid feature for larger teams on the old platform, through company plans. On the new platform, all collaboration features are 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, with post-paid billing by the day. See the price comparison. Prices can still change during the 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.

# 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 in the default domain {{app-env-id}}.{{region}}.frbit.app
• Name: Display label
  • Can be changed at any time and has no format restrictions

Apps hold environments, and each has its own ID:

A cloud domain on frbit.cloud gives an environment a named subdomain without any DNS setup.

See the removed features for what the new platform drops.

# Feedback

Feedback on any of these changes is welcome. Contact us