# fortrabbit > Developer-focused, PHP-first managed hosting platform. Scalable cloud hosting with Git-based deployments, managed databases, and transparent pay-as-you-go pricing. --- # Architecture Source: https://www.fortrabbit.com/platform/architecture Published: 2026-03-15 Reviewed: 2026-03-15 > A service-oriented platform of individually scalable components. PHP-FPM shares no resources with databases, workers or load balancing. The fortrabbit platform is service-oriented with individually scalable components. Apache/PHP-FPM does not share resources with backend other services like databases, workers or load balancing. Thus enabling better resource allocation and allowing individual configuration and scaling of resources. This design helps avoid over-provisioning, optimize resource usage, and reduce energy consumption. ## App An app is a logical grouping of environments in our dashboard, it combines billing ownership, collaboration and other settings, such as the [connection to the Git repo](/features/github-integration). ## Environments Each app has at least one environment, which exposes an actual LAMP stack. An environment can be mapped to a repo. This makes it easy to create multiple environments for multi staging. Each environment books several components that control the resources available to you. --- - [About apps](/platform/objects/app) - [About environments](/platform/objects/environment) # Infrastructure Source: https://www.fortrabbit.com/platform/infrastructure Published: 2026-03-15 Updated: 2026-08-13 Reviewed: 2026-03-15 > The infrastructure under the platform: AWS regions in Ireland and the US, isolated components, load balancing and the network between them. ## Shared resources We purchase large volumes of cloud computing resources from Amazon Web Services. Those are efficiently distributed among customers in smaller, more affordable units. This allows us to: - Optimize resource allocation - Pass savings directly to customers - Maintain high-performance standards - Ensure reliable service delivery ## Microservice oriented architecture fortrabbit is not a EC2 reseller or a server management software. The fortrabbit platform is a middleware, implemented as a Kubernetes orchestration service. It features built-in fault tolerance, health checks, auto recovery and data replication. Services such as databases run decoupled from the web server runtime in optimized containers. We make use of many AWS services, such as: Elastic Kubernetes Service, Elastic Container Registry, Elastic Compute Cloud, Elastic Block Store, Relational Database Service, Route 53, Certificate Manager, CloudWatch and CloudFront. Your benefit is a standardized solution to get you started right away at an fraction of the costs, compared to using AWS directly yourself. --- - [Environmental impact](/environment/our-measures) - [Our managed service level](/benefits/relax) - [Infra provider research 2024](/infra-research-2024) # Security Source: https://www.fortrabbit.com/platform/security Published: 2026-06-14 Updated: 2026-08-23 Reviewed: 2026-06-14 > fortrabbit runs the infrastructure and the stack, the developer owns the code on top. Each side owns its layer, nothing falls through the gap. **Separation of concerns.** fortrabbit is a managed platform: we run the infrastructure and the stack, the developer owns the code on top. Each side owns its layer in full — nothing is secured twice, and nothing falls through the gap. ## Our responsibilities - Run the stack below the app: OS, network, databases, PHP runtime, TLS, backups. - Isolate each app in hardened containers behind a default-deny firewall. - Monitor continuously, with on-call DevOps for anything out of range. - Patch the fleet, following upstream security advisories. - Maintain internal security policies, reviewed regularly. - Train staff against social engineering and phishing. - Restrict production access: least-privilege, encrypted, rate-limited. ## Developer responsibilities - Keep the framework and CMS on supported, patched versions. - Update dependencies regularly — the most common way a site gets hacked. - Store as little sensitive data as possible; encrypt what matters. - Manage access to the app, environments and team with care. - We never auto-update the application stack — by [design](/platform/no-x#no-automatic-updates). For where data lives and how compliance works, see [trust and GDPR](/trust). --- - [PHP hosting with automatic updates](/php-hosting/with-automatic-updates) - [Security measures](/legal/standards/security-measures) - [Operations](/us/operations) - [Infrastructure](/platform/infrastructure) - [Trust](/trust) # No X Source: https://www.fortrabbit.com/platform/no-x Published: 2026-03-15 Updated: 2026-09-22 Reviewed: 2026-09-22 > No cPanel, no VPS, no root, no dark patterns and no lock-in. What the platform deliberately leaves out, and what stands in its place. ## No dark patterns No vendor lock-in. No unnecessary features. No up-selling. No misleading messages. ## No servers Although the architecture is serverful and web servers are technically serving web pages here, we refer to our service as app hosting for a reason. The [architecture is service-oriented](/platform/architecture). ## No disruptive technologies No blockchain, no web 3.0, no AI, no break-through innovations. ## No 1-click installers [Laravel](/software/laravel), [Symfony](/software/symfony), [Craft CMS](/software/craft-cms) are fairly empty after initial installation. We promote using a local development environment and a [Git-based deployment workflows](/features/github-integration). One-click installers don't fit in our picture of a developer friendly service. See [Why we don't do 1-click installers](https://blog.fortrabbit.com/why-we-dont-do-1-click-installers) for the longer take. ## No automatic updates We will not update the software you have installed here. We believe that's an important separation of concern and anything else is even dangerous. As a developer, you are solely responsible for the software you bring and write here. We believe that's good. ## No free migrations We believe in empowering our users to be in control of their hosting. As a result, we do not offer free migrations from your old hosting provider as it goes against the principles of our platform. ## No excessive marketing No sales calls. No newsletters. No growth hacking. No affiliate links. No shady tricks. No engagement mails. Advertising is limited to a Google Ads remarketing tag on www, docs and blog, which does not load where consent is required. See [privacy](/benefits/privacy) for the opt-out routes. ## No affiliate program We don't have a recommend a friend program where you get paid when they become paying customers. We don't want to track that much data. But we are happy and thankful if you [recommend us](/recommend-us) anyhow. ## No root shell The SSH environment is "jailed" for security and performance reasons. You can NOT install various software such as FFmpeg, Node, NPM, Ruby on Rails, or a mail server. ## No domain registration You can add external domains to the environments. But fortrabbit is not a domain registrar, neither we provide DNS services. Use external service providers for that. ## No e-mail hosting There is no IMAP or POP3. You won't find any WebMail, also no RoundCube or SquirrelMail here. In fact `sendmail()` is disabled for security reasons. Use SMTP or an API with an external service providers for that. ## No phpMyAdmin There is no pre-installed software, such as phpMyAdmin. Use a local MySQL GUI or the command line to connect to the remote database. ## No cPanel You will not find Plesk, cPanel, ISPconfig or any classical hosting control panel with us, only our self service dashboard. ## No telephone support No sales calls. No white-glove customer service. We offer eye level developer support via Intercom, just use the small bubble in the bottom right corner. See our [contact page](/contact) how to best get in touch with us. ## No free tier No free web hosting here. We offer a [free trial](/benefits/try-free) to test before you buy. Without all the noise a free tier creates, we have the time to talk to developers who are seriously interested in our services. Without all the useless 'hello world' test sites that are 'free forever', we can offer hosting for small projects at an affordable price. ## No cheap hosting Looking for really cheap PHP hosting that is also fast, reliable and secure? This isn't the place to find massive server power for pennies. We strive to provide sustainable value at an affordable price. We don't think that cheap can actually be good either. ## No yearly payments Yearly payments are not supported. In fact, there are no upfront payments at all. Instead, we have pro-rated post-paid billing with a daily billing cycle. We believe this is the best solution to meet your fast moving needs. --- - [PHP hosting without cPanel](/php-hosting/without-cpanel) - [Hosting you](/solutions/you) - [Limits](/platform/concepts/limits) # Join us Source: https://www.fortrabbit.com/careers Published: 2026-03-15 Reviewed: 2026-03-15 > Join our globally distributed team and bring your expertise and enthusiasm. We value your unique point of view and thrive on a multicultural, international team dedicated to open source and a welcoming environment. Our culture is open, diverse, and inclusive, and we do not tolerate hate of any kind. We aim to do the right thing, even if it's harder. Find flexibility and accessibility to support your needs here. Join our globally distributed team and bring your expertise and enthusiasm. We value your unique point of view and thrive on a multicultural, international team dedicated to open source and a welcoming environment. Our culture is open, diverse, and inclusive, and we do not tolerate hate of any kind. We aim to do the right thing, even if it's harder. Find flexibility and accessibility to support your needs here. Apply only if you are in it for the mission. This is not a place for career hopping rockstars. You will earn enough to make a living, but don't apply for the money. Apply only if you have a the required skill level and if you are able to work independently. We will prefer applications from women in tech. Applications from women and other underrepresented groups are especially welcome. We love to hear from you. Contact us in any way, even when no open positions are currently listed. Send your resume to # Test for free Source: https://www.fortrabbit.com/benefits/try-free Published: 2026-03-15 Updated: 2026-10-17 Reviewed: 2026-03-15 > Every new app starts with a seven-day free trial. No credit card, no sales call, and a real environment to push a real project into. ## Try before buy Get exposed to all platform features before you make a buying decision. Test without obligations. - See if fortrabbit fits for [your](/solutions/you) needs. - Get exposed to concepts and workflows. - See if you like the dashboard. - Test different components. - Scale up and down resources. - Create multiple environments. - Experience git deployment. - Invite coworkers. - Run performance- and penetration-tests. ## Start over again and again Each app starts as a new trial. This allows you to use the trial to run a weekend hack project or to show your new project to the client before actually moving hosting. ## Ask us to extend There is a countdown with the trial app. Take care not to miss the end. Need more time to evaluate? No problem contact our support to get more time. ## Other use cases Every new app starts a free trial. That means the free trial is not only useful to discover the platform, but also for existing clients. - Rapid development - Prototypes - Preview links - Weekend hacks --- - [PHP hosting with a free trial](/php-hosting/with-free-trial) - [Trial features and limits](/platform/get-started/free-trial) # Be in control Source: https://www.fortrabbit.com/benefits/control Published: 2026-03-15 Reviewed: 2026-03-15 > An actionable dashboard, full SSH access and documentation written for developers. Managed hosting without giving up control of the app. ## Dashboard The custom build fortrabbit dashboard is the master control panel to manage all hosting related aspects - from technical settings to collaboration. It's designed for speed and accessibility, specifically made for power users. ## Docs The comprehensive documentation helps you get started and succeed quickly. Find step-by-step tutorials to deploy your chosen CMS or framework. Dive deeper into tuning and performance topics, as well as various articles related to web development. ## Separation of concerns We believe in the benefits of clearly defined areas of responsibilities. We run the hosting stack, you run the websites and web applications on it. The platform is designed with separated responsibilities in mind. Our aim is to support you as the web developer to succeed on their own. | Whom | Role | Responsibility | | ------ | --------- | --------------------------------------- | | You | Developer | Maintain software you install and write | | Client | Owner | Pay the bills | | Us | Hosting | Maintain hosting stack | - The self-service [dashboard](https://dash.fortrabbit.com) helps setting up things. - The accessible [docs](https://docs.fortrabbit.com) are full of comprehensive guides. - Each app has at least one technical contact, a developer we can reach out to, when there is some technical trouble. - Each payment method at least one billing contact, a person we can reach out to, when there is trouble with the payments. ## No automatic software updates We believe that software updates should be done by the developer who has setup the website or is maintaining it. The developer knows the code base and is usually in direct contact with the client. Software updates can sometimes require modifications at the code base level. For instance, if a new CMS update is available, it may not be supported by all the plugins used on the website. Similarly, custom configurations made by the developer may cause the website to break after an update. This could become messy quickly. Imagine we perform an update and the website breaks due to custom modifications. The blame game begins, and it becomes challenging for the client to determine who is responsible for the issue. Instead, we assist developers in handling software updates effectively by providing documentation and personal guidance in support. ## We don't know your code It's your website, your code, some 3rd party software and custom configuration, settings, plugins. We restrict ourselves from peeking into your code. We only look at your code in emergency situations or when you explicitly ask us to do so in support. But even when we would allow ourselves to peek into client code, we would not have the time to see and understand all of it. That's why it so important that you [provide details when contacting support](https://docs.fortrabbit.com/get-help/zen-support). ## Human touch Having trouble? Support to the rescue - :ContactUS ! --- - [Dev support](/benefits/get-support) # Do more with less Source: https://www.fortrabbit.com/benefits/do-more-with-less Published: 2026-03-15 Updated: 2026-09-20 Reviewed: 2026-03-27 > Start on the smallest component and scale it when traffic asks for it. Per-component sizing keeps a small project on a small bill. ## Start small, scale later The XS hosting plans are designed to provide your application with enough horse power to serve a website at an affordable price. No matter your ambitions, specifically when getting started, choose a small tier and proceed from there. Avoid premature optimization. ## XS use cases You can use our XS plans for personal projects or client work - small local business websites - low traffic projects - personal blogs - pet projects - weekend hacks - quick development - tests - design experiments ## Good code can fly Improve your code to pay less. You won't believe how fast well optimized code can serve a high number of requests even on low tier hosting plans. Design your [code for performance](https://docs.fortrabbit.com/tips/performance-design). Well optimized code also scales much better. ## Fail fast to learn fast You won't have a chance to scale well, when your code is not running well on lean hardware specs. You better experience the bottlenecks of your application sooner. Better get to know quickly, when a bot is filling your database while crawling an endless number of pages. ## Sensible limits Our tiered plans are designed with real world requirements in mind. The XS plans fit most use cases already. ## Optional components Don't need MySQL cause you are using a flat file system such as [Statamic](/software/statamic) or [Kirby](/software/kirby)? Don't book it to save a dollar each month. With [component based pricing](/pricing/details), many components are optional and each service can be scaled individually. ## Lower environmental impact By better utilizing available cloud computing resources, less energy is spend. --- - [Find the right plan](platform/get-started/choosing-a-hosting-plan) - [Green hosting](/environment/our-measures) - [Topic performance](/dev/performance) # Scale on demand Source: https://www.fortrabbit.com/benefits/scale-on-demand Published: 2026-03-15 Reviewed: 2026-03-27 > Book more resources when the app needs them, per component, from the dashboard. Performance metrics show what to scale, and when to do it. You can easily book more resources through our dashboard. Only book what is required when it is actually required, our performance metrics will help you deciding. Each component can be scaled individually. Experiment with what works best for your application. If you are unsure which plan to choose, feel free to :ContactUs. We are not here to sell you something. We recommend you [start small](/do-more-with-less), optimize your code for performance first before adding more hardware to solve a performance problem. ## Use cases Scale up for professional client work or production workloads. - High traffic websites - e-commerce - mission critical - live sites - campaigns - APIs --- - [Do more with less](/benefits/do-more-with-less) - [Topic performance](/dev/performance) # Get support Source: https://www.fortrabbit.com/benefits/get-support Published: 2026-03-15 Updated: 2026-07-20 Reviewed: 2026-05-14 > Support comes from the engineers who run the platform, over chat, in CET business hours, with a median first response under two hours. ## Self service with a human touch Our guided dashboard and the comprehensive [developer documentation](https://docs.fortrabbit.com) are self service. On top of that, we provide a fast, friendly and human customer support. ## Directly talk to us We have extensive experience in helping web developers succeed. Most questions are on web development topics such as deployment, debugging, and performance. You can also query about billing and collaboration. There is no outsourced support center. Speak to us directly. Give it a try and get in touch with us right away: ## Offload to the backchannel We assist you with anything from deployment workflows, to performance tuning, to life-cycle planning, to database support. ## Timely answers We aim to help you quickly. The median first response is under two hours. Most cases are resolved within a day. The support tool offers a chat like interface. The conversation will however not always be live. Provide details upfront. We always answer. ## Customer education Many support requests involve explaining platform features or addressing misunderstandings. For example, '500 server errors' are a frequent topic. Customers often assume they need to contact server personnel, when in fact, the error is commonly caused by code or configuration issues. In such cases, we can provide guidance on locating the logs and identifying the relevant information. ## Separation of concerns You are responsible for the code you write and install. We cannot get involved in that. By policy, we do not review client code unless requested or necessary. We believe it is important to maintain a clear line of responsibility. We will only touch your code when there is absolutely no other way. ## Support driven development On average, customers may contact us for support about 10 times throughout their lifetime with us. Through these interactions, we have the opportunity to get to know each other better. We learn about your needs and the challenges you are experiencing. This direct contact plays a crucial role in improving and expanding our service for you. We often create tickets for new ideas or service issues based on support cases and make immediate updates to our documentation. --- - [Support driven development](/support-driven-development) - [Contact options](/contact) - [Support policy](/legal/policies/support-policy) # Collaborate Source: https://www.fortrabbit.com/benefits/collaborate Published: 2026-03-15 Reviewed: 2026-01-24 > Share apps with other developers and clients: teams, per-person access, and payment methods that can be handed to whoever pays the bill. ## People-centric design The fortrabbit platform is made for humans. You sign up as an individual person. An account represents a person in real live, not an entity. This allows a much more personal but also professional experience. ## Many to many relations - Connect to multiple apps, payment methods and teams with one login. - Connect apps to multiple teams and solo developers. - Connect payment methods to individuals and teams. ## Co-ownership - Apps are owned by payment methods (not accounts). - People with access on the payment method have billing control. - Payment methods can be shared with developers, clients and teams. ## Use cases - Solo developers working for clients directly - Solo developers working for organizations - Smaller organizations with a fixed team - Bigger organizations with multiple teams ## Example workflows - Invite clients and non-devs to take over billing - Create teams to share apps with other developers - Pass over app access from developer to developer --- - [The person object](/platform/objects/person) - [Account organization](/platform/concepts/account-organization) - [Collaboration into](/platform/collaboration/intro) # Hand over Source: https://www.fortrabbit.com/benefits/hand-over Published: 2026-07-20 Updated: 2026-08-23 Reviewed: 2026-07-20 > Client work ends and somebody has to own the hosting. How to hand an app, its bill and its access over without moving the site anywhere. Client work ends. At some point the site is live, the invoice is paid, and somebody has to answer who is responsible for the hosting from now on. Most hosting arrangements answer that badly, which is why so many finished projects sit on an agency account years later, quietly billed to the wrong party. ## Ownership and infrastructure are separate The usual reason a handover hurts is that ownership was tied to infrastructure, so changing one meant moving the other. An app here has an owner, and that owner can change without the app moving. Code, database, domains, certificates, and environment variables stay exactly where they are. That turns a handover into a short administrative act rather than a project. There's no migration window, no DNS propagation to wait out, and nothing to re-test afterwards, because nothing about the running application was touched. ## Billing follows ownership Once a client's account takes over an app, the charges appear there. Payment methods are held per account, so the agency card is not involved after the transfer, and nobody is passing hosting invoices through with a markup. Billing is pro-rated and post-paid by the day, so a transfer that lands mid-month doesn't mean either side pays twice for the same period. ## Access outlives ownership Handing over the account doesn't have to mean handing over the work. Most clients who take ownership still want the person who built the site to keep maintaining it, and most developers want a maintenance retainer to survive the handover. Access is granted per person and per app, separately from ownership. A client can own an app, pay for it, and still have granted the original developer the deploy and SSH access needed to keep working on it. That access can also be revoked without touching the app, which is what makes a clean break clean when the relationship genuinely ends. ## It works in every direction Handover is not only agency to client. A freelancer growing into an agency, a contractor swapping out mid-project, a client bringing development in-house, an agency inheriting a site somebody else built — they're all the same operation. Teams map the same way. People join and leave, roles change, and an app can be shared across teams when more than one party needs it. None of that requires touching the application. ## Build for it from the start Handovers go badly when they're discovered at the end. A few decisions made early decide whether it's a five-minute operation or a week of archaeology. Configuration belongs in environment variables rather than in code, so credentials can be rotated by the new owner without a deployment. Anything scheduled belongs in the jobs component rather than in somebody's personal crontab. Uploaded files belong in the storage component rather than on a local disk. Each of these keeps an application self-describing, which is what makes it transferable — and maintainable by whoever comes next. --- - [The person object](/platform/objects/person) - [Collaboration intro](/platform/collaboration/intro) # Stay private Source: https://www.fortrabbit.com/benefits/privacy Published: 2026-03-15 Updated: 2026-09-22 Reviewed: 2026-09-22 > Privacy by design: GDPR terms by default, a data processing agreement on file, no cookie banner anywhere, and a German company answerable under EU law. ## GDPR / CCPA compliant The European privacy standard GDPR was developed here in Germany. It's not perfect, but we proudly support it [since 2018](https://blog.fortrabbit.com//fortrabbit-is-gdpr-ready). ## No cookie banner Notice something missing? There is no cookie consent banner on any fortrabbit website. Where advertising cookies need opt-in consent — the EEA, the UK, Switzerland, Brazil and Quebec — no advertising tag is loaded here, so there is nothing to consent to. Everywhere else, a Google Ads remarketing tag runs on www, docs and blog and sets advertising cookies, which is what the notice-and-opt-out laws in those jurisdictions allow. The dashboard carries no advertising tag at all. Functional cookies are used on every property: a session, a currency, a color scheme. Those are set by fortrabbit and shared with no one. ## What an ad blocker finds An ad blocker flags the Google Ads tag wherever it loads. It finds no fingerprinting and no session recording. Visit statistics come from Fathom, configured without cookies. No page here depends on the advertising tag, so blocking it breaks nothing. ## Do Not Sell or Share My Personal Information Under the California CPRA and the comparable state laws, running a remarketing tag counts as sharing personal information for cross-context behavioral advertising. Two settings stop it: - [Global Privacy Control](https://globalprivacycontrol.org) — a browser setting or extension that sends an opt-out signal. fortrabbit reads that signal and loads no advertising tag for that visitor. - [Google Ad Settings](https://myadcenter.google.com) — switches off personalized advertising across everything Google serves. An ad blocker, or a browser that blocks third-party cookies, has the same effect. ## US state privacy rights Residents of US states with comprehensive privacy laws — California, Colorado, Connecticut, Virginia, Utah and the states that followed — can ask what personal information fortrabbit holds, have it corrected or deleted, and opt out of targeted advertising. Requests go through the [DSAR policy](/legal/data-protection/dsar-policy), which is open to everyone and not limited to residents of any one place. Personal information is not sold for money. ## No AI feeding We don't sell or use your data or code training LLMs to replace you one day. We do use AI to create and extend this service. We try to do so in a responsible way, see our [AI usage policies](/legal/policies/ai-usage-policy). ## Data processing as a service Beside storing data on our clients directly, we also process data for our clients. Our general [data processing agreement](/legal/data-protection/data-processing) serves as the legal basis for doing that. ## 3rd parties transparency fortrabbit wouldn't be possible without the use of other services. Many of them are based in the US. External service partners are chosen after careful consideration. We try to find a good balance of service level, privacy and other factors, such as [environmental impact](/environment/our-measures). Google is one of them. Where the remarketing tag loads, Google learns that a browser opened www, docs or blog and can show fortrabbit ads to that browser on other sites later. No account data and no app data goes with that tag. Accounts created after a Google ad click are credited back to that ad. A nightly job sends Google the click ID, the signup time and the time of the first payment, with an identifier made of the event type and the account ID. Name, e-mail address and app data are not sent. Object to it by e-mail to , see the [privacy statement](/legal/data-protection/privacy-statement). We maintain a public list of [sub processors](/legal/data-protection/sub-processors), including what data is shared and why. ## Opt-in where possible Certain platform features are optional. Agree before using the 3rd party customer chat service. Social sign up is also optional, as well as Git deployment with a third party. ## Data minimization The less we know, the better. Server logs are only stored as long as required and anonymized where possible. Idle accounts are getting deleted automatically. We have a zero inbox mentality when it comes to storing data. ## Deletion of abandoned accounts We delete old and neglected accounts when all of the following attributes are given: - no login to our dashboard for a long time - no access to any team - no active apps running We think that is in the best interest of our users for privacy and security. It's easy to sign up again at any time later. We might not inform the Account about an upcoming auto-delete. ## Purpose limitation Your data is not getting horded. We only store data points for good reasons, either to improve the service experience or to make it more secure. ## Security for privacy Many of our security features are aimed to protect your privacy. Data is encrypted where possible. Only secure access protocols are allowed. Strict policies and workflows are in place. ## Use cases fortrabbit is a web hosting to serve websites and web applications. Some data stored by our clients is public, think websites fully accessible from the world wide web. Other data is private, often behind a login, think software services or eCommerce. ## Limits fortrabbit might not be suited to store very sensible data such as health related, financial data or a lot of personal records. As much as we would personally love to host everything within EU or even just DE bounds, we also want to offer our solution internationally. --- - [Trust](/trust) - [Security](/platform/security) - [Privacy statement](/legal/data-protection/privacy-statement) - [Data processing](/legal/data-protection/data-processing) - [Data collection and retention](/legal/data-protection/data-collection) - [Sub processors](/legal/data-protection/sub-processors) - [DSAR policies](/legal/data-protection/dsar-policy) # Cancel at any time Source: https://www.fortrabbit.com/benefits/cancel-any-time Published: 2026-03-15 Reviewed: 2026-03-27 > Cancel an app or the whole account from the dashboard. Effective immediately, pro-rated and post-paid, with no contract term to sit out. ## Exit strategy built in Lost interest? Client troubles? Budget constraints? We've been there. We make it simple when you need to leave: - **Immediate effect** - Billing stops instantly when you're ready - **No penalties** - Zero early termination fees or cancellation charges - **Data export** - Download backups to keep your data - **Personal support** - Contact support to discuss your cancellation See our [cancellation help](/contact/service-cancellation). ## No lock-in Other providers lock you into pre-paid, long-term contracts spanning years. Not here. Cancel anytime with immediate effect in just a few clicks. Pay only for what you've actually used, for exactly as long as you've used it. ## Partial cancellation No need to cancel everything at once. Our flexible pricing supports cost optimization with granular control: - **Scale down components** - Reduce CPU, memory, or storage as needed - **Remove environments** - Delete staging or development environments when done - **Delete individual apps** - Remove specific projects while keeping others running ## Seamless handovers Planning to transfer projects? We make handovers smooth and straightforward: ### Client handovers - **Client invites** - Request clients take over billing responsibility - **Ownership transfer** - Move apps and environments to client accounts - **Billing transition** - Seamlessly transfer payment responsibility - **Access management** - Grant client access while maintaining involvement as needed - **Data continuity** - Code, databases, and configurations transfer completely intact ### Team transitions - **Team membership changes** - Add or remove team members without disruption - **Role adjustments** - Change access levels and permissions as teams evolve - **Multi-team projects** - Share apps across teams when collaboration is needed ### Developer transitions - **Freelancer to agency** - Smooth transition when projects scale up - **Contractor changes** - Zero disruption when switching development teams - **Agency to in-house** - Easy handover when clients bring development internal --- - [Terms and conditions](/legal/contract/terms) - [Post paid billing](/platform/billing/postpaid) - [Reduce hosting costs](/dev/how-to/reduce-hosting-costs) - [Cancellation help](/contact/service-cancellation) # Relax Source: https://www.fortrabbit.com/benefits/relax Published: 2026-03-15 Reviewed: 2026-03-15 > Bring the code, the platform runs the rest: OS patches, PHP updates, TLS certificates, backups and the machines underneath them. ## A standardized solution As a small team we strive for the highest degrees in automation to improve service quality and reduce the number of tasks that need to be done by humans. Therefore the service is highly standardized, yet flexible offering a wide range of different use cases. ## Human maintainance We pride ourselves for being able to handle operations with a small team. Yet. You won't believe how much human observation, interaction and intervention it takes. Behind the scenes, there is a significant amount of maintenance required to keep the platform up and running. Over the years, we have developed extensive DevOps routines to ensure smooth operation and minimize the chance for human errors to sneak into production. Such a large infrastructure system is intricate. There are edge cases and customers constantly presenting unique requirements. Additionally, there are unpredictable events such as critical CVEs and hacker attacks that demand swift response. These challenges are our bread and butter. --- - [Service level agreement](/legal/contract/service-level-agreement) - [Security measures](/legal/standards/security-measures) - [Developer support](/benefits/get-support) # GitHub integration Source: https://www.fortrabbit.com/features/github-integration Published: 2026-03-15 Updated: 2026-09-23 Reviewed: 2026-09-23 > The fortrabbit GitHub app lives on GitHub: github.com/apps/fortrabbit. The fortrabbit GitHub app lives on GitHub: [github.com/apps/fortrabbit](https://github.com/apps/fortrabbit). It connects Git repos hosted on GitHub with the fortrabbit hosting platform. Each Git repo maps to an app, and branches map to environments. Configure it to deploy on each git push or deploy manually through the fortrabbit dashboard. Deployments can be tracked and observed in the dashboard too. The deployment service integrates with collaboration features, see who deployed what and when. ## GitHub Actions alternative Deployment is more than moving code from a Git repo to a web space. In between the fortrabbit deploy service can install dependencies and build artifacts. The software template defaults for deployment will pre-configure common settings. Comprehensive settings allow many workflows, from deployment strategy, to exclude and include patterns, to source directory settings. Most settings allow zero-downtime deployments. Caching speeds up successive deployments. --- - [PHP hosting with git push deploy](/php-hosting/with-git-push-deploy) - [GitHub integration](/platform/deployment/github-app) - [Build commands](/features/build-commands) # Build commands Source: https://www.fortrabbit.com/features/build-commands Published: 2026-03-15 Reviewed: 2026-03-15 > Run Composer, npm or any build step on every deploy. Build commands turn a git push into a repeatable pipeline with an atomic release. ## Architecture Build commands run on an isolated deploy service, which operates independently from the environment runtime. ```raw 1 Local 2 Git provider 3 fortrabbit 4 environment ┌─────┐ ┌────────────┐ ┌──────────────┐ ┌──────────────┐ │ Git ├───▶ Git repo ├───▶ Deployment ├───▶ web space │ └─────┘ └────────────┘ └──────────────┘ └──────────────┘ ``` ## GitHub Actions not required Software deployment can be complex. Our goal is to support common standards out of the box, while remaining flexible for different workflows. For most common software installations, no configuration is needed here. Our software templates automatically pre-populate standard tasks like `composer install` based on your selected software and components. GitHub Actions are not required either, as the fortrabbit GitHub App connects directly to your repositories. Deployments run on fortrabbit, not on GitHub. However, you can also integrate GitHub Actions as an alternative deployment method if you prefer. ## Runtimes and libraries The deployment service runs in a dedicated, isolated container with the same software versions available as in your environment. **Composer:** Installs the latest PHP dependencies as defined in your `composer.json`, specifically tailored for the hosting environment. **Node.js:** Executes `npm run prod` or similar commands with each deployment to generate JS and CSS assets to be served by your application. ## Automatic deployment cancellation If the build commands fail for any reason, the deployment will be aborted. ## Post deploy commands While most deployment-related tasks should run in a separate service, some actions—like migrations and cache busting—need to run on the actual web runtime. That's what post deploy commands are for. --- - [GitHub integration](/features/github-integration) - [Topic deployment](/platform/deployment) - [Build commands](/platform/deployment/build-commands) - [Post deploy commands](/platform/deployment/post-deploy-commands) # Staging environments Source: https://www.fortrabbit.com/features/staging-environments Published: 2026-03-15 Updated: 2026-09-23 Reviewed: 2026-09-23 > Run the same application in separate but similar environments. Try changes on staging, promote them when they hold, keep production quiet. **Move fast, break nothing.** Experiment with confidence and without downtime. ## Stateful and isolated The fortrabbit platform is serverful, as PHP is a server-side language. This means environments are stateful. An environment is more than deployed code and artifacts — it also contains runtime data such as logs, sessions, uploads, and the state of a database. Each environment is a fully isolated hosting environment. Services run completely separated from each other, ensuring there is no performance interference. Environments have their own components, which can be scaled individually. Use smaller setups for development and staging to save costs and resources. ## Use cases Multi-staging is the opposite of "open heart surgery"—it's a best practice for running the same application in separate, but similar, environments. This approach is especially valuable for teams, but solo developers can benefit as well. Typical use cases for multi-staging include: - Development: Safely build and test new features - Testing/QA: Verify new releases - Staging: Final review, client demos - Hotfixes: Test urgent fixes in isolation Reduce the risk of unexpected issues in production. --- - [PHP hosting with staging environments](/php-hosting/with-staging-environments) - [The environment object](/platform/objects/environment) - [Multi staging concepts](/dev/learn/staging-environments) # Test domain Source: https://www.fortrabbit.com/features/test-domain Published: 2026-03-15 Updated: 2026-04-04 Reviewed: 2026-04-04 > Every environment gets a free test domain with a TLS certificate, served over HTTPS. Preview and share work before any DNS is touched. Preview your work in a real environment before going live. No DNS setup required — deploy and share a link right away. All test domains come with a pre-installed TLS certificate and are always served over HTTPS. ## Use cases - **Client review** — share a link to gather feedback without touching production. - **Staging** — each environment gets its own unique test domain, think feature branch previews. - **CI/CD** — reference the test domain in automated tests or health checks. --- - [Test domain docs](/platform/dns/test-domain) # Free certificates Source: https://www.fortrabbit.com/features/free-certificates Published: 2026-03-15 Reviewed: 2026-03-15 > Free TLS certificates for every domain and every test domain, issued and renewed automatically. HTTPS everywhere with zero configuration. - All domains will automatically get a TLS certificate installed - Certificates are renewed automatically - Issuance usually completes a few minutes after the domain resolves - Renewals are attempted well before expiry; no downtime is expected - Forward all traffic from http to https directly - Forwarded apex domains get TLS certificates as well --- - [HTTPS intro](/platform/dns/https) - [HTTPS troubleshooting](/dev/learn/https-troubleshooting) # SSH key authentication Source: https://www.fortrabbit.com/features/ssh-key-authentication Published: 2026-03-15 Updated: 2026-09-23 Reviewed: 2026-09-23 > Public key authentication is more secure and more convenient than passwords. Upload public keys to the dashboard to connect by SSH and SFTP. Public key authentication is more secure and more convenient than passwords. Upload public keys to the dashboard to connect by [SSH and SFTP](/features/ssh-sftp). ## Individual code access The fortrabbit collaboration features are designed for people working together. Instead of shared hosting accounts, developers create individual accounts. This makes the system transparent, observable and manageable. Personal code access is a key ingredient of this. Onboard and offboard developers without resetting shared passwords. ## Special code access for services Create deploy keys for external services, such as GitHub Actions, to automatically connect to environments. --- - [SSH key setup guide](/tips/ssh-keys) - [Code access intro](/platform/code-access/intro) # SSH and SFTP Source: https://www.fortrabbit.com/features/ssh-sftp Published: 2026-03-15 Reviewed: 2026-03-27 > Full SSH and SFTP access to a hosted app: run artisan or wp-cli, read files, move a database. Direct access, without root on the machine. ## Sync runtime data [Git deployment ](/features/github-integration) is recommended. But websites usually produce additional runtime data such user uploads. Keep that in sync with SSH or SFTP. Use the power of [rsync](https://docs.fortrabbit.com/dev/how-to/rsync) to extend your deployment or create unique deployment workflows. ## Debugging Login by SSH to examine the deployed files directly. Check logs and runtime data directly. Run commands. ## Legacy SFTP workflows Not yet ready to use Git, or need to deploy a [WordPress](/software/wordpress) website? No problem. Spin up your SFTP client, setup [SSH key authentication](/features/ssh-key-authentication) and upload your website. --- - [PHP hosting with SSH access](/php-hosting/with-ssh-access) - [SSH key authentication](/features/ssh-key-authentication) - [SSH usage guide](/platform/code-access/ssh) - [SFTP usage guide](/platform/code-access/ssh) - [Code access intro](/platform/code-access/intro) # MCP server Source: https://www.fortrabbit.com/features/mcp-server Published: 2026-08-23 Updated: 2026-08-24 Reviewed: 2026-08-23 > Connect a coding agent over MCP: it reads environments, opens a staging environment, checks a failed build and sets the variable that fixes it. With the MCP integration you don't need to switch between browser and terminal that often any more. Also, you don't need to know all the specifics. With the MCP tooling your AI chat buddy will gain tools to up environments, open a staging environments, reads the build output of a deployment that failed. [MCP setup instructions](/mcp) Every tool the agent gets, what it may change, and how a connection is revoked: [MCP server documentation](/platform/automation/mcp) ## FAQ ### Which agents can connect? **Anything speaking MCP** — Claude Code, Codex, Cursor and VS Code have a documented setup command each. Any other MCP client works against the same endpoint. A client without OAuth support authenticates with a personal API token instead. ### What can an agent actually change? **Three things** — Most tools read. Three write: creating an app, creating an environment, and updating environment variables. Restarts, deletions and standalone deployments are not exposed — a REST endpoint existing does not make it available to agents. ### Can an agent see more than the person who connected it? **Never** — A connection carries the authorization of the person who approved it and sees exactly what that person sees in the dashboard. The access token expires after one hour and the refresh token after 30 days, both bound to that one agent. ### How is a connection revoked? **From either side** — Clearing the authentication in the agent drops the access token and the refresh token together, so it cannot quietly renew. Disconnecting on the account side ends every connection that agent holds — the route to take when the machine running it is out of reach. ### Is it ready for production work? **It is in testing** — The MCP server is in testing, and the platform around it is in beta. Reading environment variables returns the values fortrabbit injects, database credentials among them, and whatever an agent reads lands in the context of the connected client. Worth a thought before pointing one at a production environment. --- - [Agent skills](/features/agent-skills) - [Agentic engineering](/workflows/agentic-engineering) - [MCP server docs](/platform/automation/mcp) # Public API Source: https://www.fortrabbit.com/features/public-api Published: 2026-08-23 Reviewed: 2026-08-23 > Everything the dashboard does, scriptable. Apps, environments, deployments and domains over HTTP, addressed by the same short IDs. **Everything the dashboard does, scriptable.** Apps, environments, deployments and domains over HTTP, addressed by the same short IDs the dashboard shows. What gets done by clicking can be done by a pipeline, a script or an agent instead. ## The layer under everything else The [CLI](/features/cli) is a client of this API, and the [MCP server](/features/mcp-server) is how agents reach it. Anything built directly against it sits at the same level as the tools fortrabbit ships — no second-class interface, no scraping a dashboard that was not built to be scraped. ## A reference that cannot drift The endpoint reference is generated from the API itself, so it always describes what the API actually accepts. [API reference](https://api.fortrabbit.com/v1/docs) Tokens, the entry point and the rate limits, with worked examples: [Public API documentation](/platform/automation/api) ## FAQ ### What does the API cover? **The dashboard objects** — Apps, environments, deployments, domains, teams, people and payment methods. Objects are addressed by the same short public IDs the dashboard shows, and collections take a repeated publicId[] parameter to fetch several known objects in one call. ### How does authentication work? **A personal token** — A token is created in the dashboard and passed as a bearer credential on every request. It acts as the person who created it and sees exactly what that person sees. Tokens do not expire; unused ones are deleted, which takes effect immediately and leaves every other token working. ### Are there rate limits? **Around 20 per minute** — Requests are counted per token in a sliding one-minute window. Every response carries the limit, the remainder and the reset; a rejected request answers 429 with the seconds to wait. Failed authentications are counted separately, per IP address. ### Is the API stable? **It is in beta** — The API is in beta like the platform around it, so breaking changes are possible. The /v1 prefix marks the shape of the API — pin nothing that cannot be adjusted. --- - [CLI](/features/cli) - [MCP server](/features/mcp-server) - [Public API docs](/platform/automation/api) # frbit CLI Source: https://www.fortrabbit.com/features/cli Published: 2026-08-23 Reviewed: 2026-08-23 > frbit is the fortrabbit command line interface. Deploy, read build output, set a variable and list what is running, without the dashboard. There is a self-service dashboard. Some prefer the terminal. `frbit` is our command line interface to operate the platform. Deploy, read the build output, set a variable, list what is running. * [github.com/fortrabbit/frbit-cli](https://github.com/fortrabbit/frbit-cli) ## Automation on a documented interface Everything it does is a call to the [public API](/features/public-api). `--json` prints the response unchanged for whatever runs next. ## AI Agent support `frbit setup agent` detects Claude Code and Codex, registers the [MCP server](/features/mcp-server) with each and installs the [agent skills](/features/agent-skills). It is the shortest path from a fresh machine to an agent that can operate the platform. Install routes for macOS, Linux and Windows, and every command with its options: [CLI documentation](/platform/automation/cli) ## FAQ ### What does it need installed? **Nothing** — The CLI is a self-contained binary with no runtime dependency, which is what makes it fit a CI pipeline or a container as easily as a laptop. Install with the script, with Homebrew, with npm, or from the release archives — Windows included. ### How does it authenticate in CI? **One environment variable** — An interactive session signs in once and the credential lands in the operating-system credential store. A job passes FRBIT_TOKEN for a single process instead, which takes precedence over anything stored. Separate accounts are kept apart by profile. ### Can it be used in a script? **That is what --json is for** — Read commands print the API response unchanged with --json, ready for jq. Bear in mind that responses can carry environment-variable values and application log output, so CI logs deserve the same care as a terminal capture. ### What does it have to do with agents? **It sets them up** — One command detects the installed coding agents, registers the MCP server with each and installs the latest agent skills. One command takes a fresh machine to an agent that can operate the platform. --- - [Public API](/features/public-api) - [MCP server](/features/mcp-server) - [CLI docs](/platform/automation/cli) # Agent skills Source: https://www.fortrabbit.com/features/agent-skills Published: 2026-08-23 Reviewed: 2026-08-23 > Skills that carry the procedure: connecting a project, deploying, syncing files, moving a database. A coding agent runs them, not guesses. **The agent runs the procedure.** Reading the documentation is not the same as performing the operation correctly. The skills carry the workflows — connecting a project, deploying, syncing files, moving a database, running a remote command — so a coding agent executes them instead of reconstructing them from prose. ## Operations by name `/fortrabbit deploy` deploys. `db down` pulls the database. `ssh` runs artisan, craft console or Composer on the environment. A procedure looked up once a month becomes one command. ## With or without a connection The skills work over SSH and rsync on their own. Adding the [MCP server](/features/mcp-server) lets the agent list apps, open environments and read deployment logs without a shell. The two work together. They are open source, so what an agent is being told to do can be read before it does it. [Agent skills on GitHub](https://github.com/fortrabbit/agent-skills) Install, per-agent setup and the full command list: [Agent skills documentation](/platform/automation/agent-skills) ## FAQ ### Which agents do they work with? **Claude Code and Codex** — Both are supported directly, and GitHub Copilot has basic support. Installing is one command, globally or per project, and uninstalling lists what it will delete before removing anything. ### Is an MCP connection required? **No** — The skills work over SSH and rsync on their own. Adding the MCP server lets the agent list apps, create environments and read deployment logs without a shell — the two halves compose rather than compete. ### What do they actually do? **The everyday operations** — Detect the project and connect it, deploy, sync files up or down, move a database in either direction, move CMS content, and run a remote command over SSH — artisan, craft console, Composer. ### What do they need locally? **ssh and rsync** — Both have to be available. On Windows, rsync and the install script need WSL; SSH itself works natively on Windows 10 and later. --- - [MCP server](/features/mcp-server) - [Agentic engineering](/workflows/agentic-engineering) - [Agent skills docs](/platform/automation/agent-skills) - [Source code](https://github.com/fortrabbit/agent-skills) # Jobs Source: https://www.fortrabbit.com/features/jobs Published: 2026-03-15 Updated: 2026-09-23 Reviewed: 2026-09-23 > Worker and cron jobs as an optional component: dedicated PHP processes for background work, isolated from the web front-end. Jobs, available as an optional component, run scheduled and continuous commands. These dedicated back-end PHP processes are isolated from the web front-end, ensuring fast website delivery while handling heavy processing tasks in the background. Worker and cron jobs are well supported by modern PHP frameworks like [Laravel](/software/laravel) and [Symfony](/software/symfony), as well as content management systems like [Craft CMS](/software/craft-cms) and [Statamic](/software/statamic). ## Features - **Easy setup**: manage and monitor jobs with the fortrabbit dashboard - **Compatible**: works with common PHP frameworks and CMSs - **Reliable**: automatic restarts, observable logs - **Scalable**: grow on demand and handle increased workloads --- - [The jobs component](/platform/components/jobs) - [Non-stop worker jobs](/platform/jobs/workers) - [Working with cron jobs](/platform/jobs/crons) # MySQL Source: https://www.fortrabbit.com/features/mysql Published: 2026-03-15 Updated: 2026-09-23 Reviewed: 2026-09-23 > Managed MySQL as its own component: isolated from the PHP runtime, sized separately, reachable over an SSH tunnel and included in backups. ## About MySQL MySQL is a versatile open source database that needs no introduction. Many web-based content management systems, including [WordPress](/software/wordpress), [Craft CMS](/software/craft-cms), and [Drupal](/software/drupal) are powered by MySQL. MySQL is the M in LAMP. ## MySQL on fortrabbit MySQL is available as an optional individually scalable component. With the fortrabbit [app architecture](/platform/architecture) it runs isolated from the PHP runtime. It can be booked and scaled individually for each environment. Shared plans cover average workloads, dedicated plans offer individual performance. Autoscaling books larger plans as the database grows. Environment variables pre-configure the database connection for most popular PHP open source software. Connect to the remote MySQL database from a local machine over an SSH tunnel using Sequel Ace, TablePlus, MySQL Workbench or a local installation of phpMyAdmin. Extensive documentation with live code examples is available. --- - [The database component](/platform/components/database) # Backups Source: https://www.fortrabbit.com/features/backups Published: 2026-03-15 Updated: 2026-09-23 Reviewed: 2026-09-23 > Offsite copies of code and database, taken on a schedule and restorable from the dashboard. Backups are an optional component per app. ## Features - Automated daily backups - Manual backups on demand - Restore from backup - Intelligent retention policy - Offsite storage ## Use cases - Developer mistakes - Content editor errors - Hacked website - Dependency issues ## Stateful backups The fortrabbit platform is stateful by design. Backup snapshots capture the complete state of the environment including application files, runtime data, user uploads and database contents for data integrity. This enables restoring environments from backups. --- - [PHP hosting with backups included](/php-hosting/with-backups-included) - [The backup component](/platform/components/backups) - [Backup files](/backups/files) - [Backup restoration](/backups/restore) # Docs Source: https://www.fortrabbit.com/features/docs Published: 2026-03-15 Updated: 2026-08-23 Reviewed: 2026-08-23 > Hosting documentation written for developers and for coding agents: platform reference, install guides and dev tips, all in plain markdown. ## Publicly accessible docs Please RTFM. The documentation is right here: - [docs.fortrabbit.com](https://docs.fortrabbit.com) - all pages sorted and searchable - [github.com/fortrabbit/docs](https://github.com/fortrabbit/docs) PRs welcome! ## Agent-ready docs Too Long Didn't Read ~200 articles? The documentation is structured and written to be read by human developers and coding agents alike: clear explanations, consistent formatting, worked examples. Machines get the same pages without the page furniture, which costs a fraction of the tokens: - every article answers to `Accept: text/markdown` with the raw Markdown - [docs.fortrabbit.com/llms.txt](https://docs.fortrabbit.com/llms.txt) - links to all markdown articles - [docs.fortrabbit.com/llms-full.txt](https://docs.fortrabbit.com/llms-full.txt) - full docs on one markdown page - [the agent skills manifest](https://docs.fortrabbit.com/.well-known/agent-skills/index.json) - what the published [agent skills](/features/agent-skills) can do Reading is only half of it. The [MCP server](/features/mcp-server) lets an agent act on what it read. ## Comprehensive coverage Beyond platform-specific guides, the documentation serves as a knowledge base and learning resource covering: - Platform fundamentals: Components, deployment … - Development workflows: Local development, Git workflows … - Framework guides: Laravel, Craft CMS, WordPress … - Best practices: Security, performance optimization … - Troubleshooting: Common issues and solutions ## Maintained and current Consistent structure and quality throughout, regularly updated, community contributions welcome, version tracked via Git. --- - [Agent skills](/features/agent-skills) - [MCP server](/features/mcp-server) - [Docs](/) # Our history Source: https://www.fortrabbit.com/us/history Published: 2026-03-15 Updated: 2026-05-15 Reviewed: 2026-04-29 > fortrabbit has been hosting PHP projects since 2012, with roots going back further. The milestones, the pivots and the platform rewrites. ## Founding partners - Ulrich Kautz - Oliver Stark - Frank Lämmer ## 2004 - Early days Over two decades ago, back in 2004, we already offered a range of internet-related services, mostly about web design, but also including web hosting, e-mail and domain registration. As a network of connected developers we worked for a variety of clients. We mostly implemented standard websites with [WordPress](/software/wordpress), but we also touched Textpattern, Drupal and Typo3. ![Website](/images/fortrabbit-website.png) The hosting aspect back then primarily involved reselling our root server resources. See a [capture of our website fortrabbit.de](https://web.archive.org/web/20040502130143/http://www.fortrabbit.de/dienst.html) from 2004 in the internet archive. ## 2007 - Getting more serious As an agency we started implementing more custom build dynamic websites, usually in CakePHP, since [Laravel](/software/laravel) was not around yet. We also decided to separate the hosting services from the agency business. So we fortrabbit became a hosting side gig project. We purchased servers and set them up in a data center in Berlin to indulge in our passion for technology, product development, and meeting customer needs. We combined infrastructure and software into a hosting system called MISH. MISH offered distributed services, variable resources billed on consumption, and a mix of automation and customization, similar to a blend of modern shared hosting and managed hosting. ![Servers](/images/server.jpg) However, the MISH hosting solution had limitations in scalability due to its hardware components. We had a new vision: to narrow our focus and build a hosting platform that would better address our own needs, specifically tailored for modern and professional PHP web development. ## 2012 - fortrabbit GmbH We made the decision to abandon all of our web agency client projects and focus exclusively on this project. In 2012, we implemented our new cloud hosting solution using AWS. It was the first European Platform as a Service specifically designed for PHP, which was a perfect fit for the growing PHP renaissance and the yet still young Laravel scene. ## 2015 - V2 Ever since we have been developing our platform with all kind of ups and downs. In 2015, we launched a major platform upgrade. In 2016, we introduced the third generation of Apps, called Universal Stack, and also opened our second data center location in the US. ## 2016 - 2021 The next years we have mostly been busy scaling operations. ## 2022 - New platform vision After a lot of thinking and long discussions, we began developing the new platform version in 2022. ## 2023 - New platform in the making We are busy building the new platform. ## 2024 - New platform still in the making We are still busy building the new platform. ## 2025 - New platform coming to light Private alpha launches in March. Public beta launches in November. ## 2026 - Forward to public launch We are looking forward to achieve feature parity and full stability for the new platform. --- - [The fortrabbit chronicles](/tag/chronicles) # Our culture Source: https://www.fortrabbit.com/us/culture Published: 2026-03-15 Updated: 2026-06-03 Reviewed: 2026-06-03 > How a small bootstrapped hosting company works: remote by default, no investors, no growth targets, and a product built to scratch our own itch. ## Vision fortrabbit is a lifestyle business. As developers and product people ourselves, we created this service to scratch our own itch. We have [firsthand knowledge](/history) of what it takes to build and maintain websites. We are in it for the long run. Our primary metric is the longevity of customer relationships, not new acquisitions, share holder value or successful exits. ### Design philosophy We aim to make things useful and accessible, easy but never simplistic. We aim to help you achieving your goals. We don't want to engage you. There is no eye candy. Design for us is removing things until perfection is achieved. ### Supporting craftsmanship In times of AI and no-code website builder solutions, we find joy in the ancient witchcraft of manually creating websites in the text editor. We perceive the internet not just as a platform for consumption, but for creation. A space that welcomes builders, tinkerers, indie hackers, learners, and underdogs. A space where ideas can thrive and compete. We believe web technologies empower creative individuals to achieve remarkable feats. They transcend national boundaries and foster unity. ### Loving an open web We love open source software and heavily depend on it to provide this service. We hope to be able to give back to FOSS more in the future. ### Encourage not enforce We promote modern development practices, but won't force them. Good backwards compatibility is one of our core values. ### AI usage This is not some quickly prompted thing. We use artificial intelligence as a tool to help us move faster. Our code bases need to be kept maintainable by humans. AI may be used to craft code, write tests, review PRs, prototype ideas, review and brainstorm documentation, find tpyos and correct spelling. We are careful about it. See our [AI usage policy](/legal/policies/ai-usage-policy). ## Sustainability For us, sustainability has many facets. It's not about claiming a negative CO2 budget for marketing reasons. It's more holistic. ### Business model It begins with our customers, who hopefully find value in our service, work with it, and stick with it. The same principle applies to our team. We are not pursuing this endeavor solely to enhance our CV, expend investor funds, or seek an exit. We have chosen this path because we genuinely believe in it. ### Working environment We aim to provide good working conditions where creativity can prosper. We work goal oriented, but without rush. We don't hustle. As a remote team, the human connection is sometimes harder to maintain. Mental health is on our radar. ### Environment We don't believe in 'green hosting', but we do best to keep our [environmental impact](/environment/our-measures) low. ## Privacy Not selling nor sharing your data is one of our core principles. See our [privacy features page](/benefits/privacy) as an entry point. --- - [Environment impact of hosting](/environment) - [Posts tagged 'chronicles'](/tag/chronicles) # Operations Source: https://www.fortrabbit.com/us/operations Published: 2026-03-15 Reviewed: 2026-03-15 > How the platform is run day to day: who is on call, how incidents are handled, how updates ship, and what running it costs in attention. ## DevOps We plan updates, create maintenance windows, run tests, roll out new software versions, stay on call, fix incidents quickly, write post-mortems, improve routines and code as required on steady basis. ## Security We stay on alert for abuse and CVEs, read reports, validate evidence, notify affected customers, coordinate legal requests, balance takedowns with fair use. ## Development We continuously improve the platform, add new features, fix bugs and find new ways of automation. ## Support We interpret ambiguous questions, explain stuff, offer solutions, suggest alternatives, reproduce edge cases, help recover accounts, offer advice with your hacked website, listen for feedback, even speak with your clients too. ## Billing We handle international tax laws, review failed payments, find your invoices and clarify contract questions. --- - [About us](/us) - [Security](/platform/security) - [Security measures](/legal/standards/security-measures) - [Get tech support](/benefits/get-support) - [Our AI policy](/legal/policies/ai-usage-policy) - [Why not Coolify?](/alternatives/coolify) # Cost breakdown Source: https://www.fortrabbit.com/us/cost-breakdown Published: 2026-03-15 Updated: 2026-08-13 Reviewed: 2026-03-27 > Where the money goes: what a hosting plan pays for, how fortrabbit spends it, and why the price is what it is. A look at the actual books. | Category | Share | | ----------------------------------- | ----: | | [Human resources](#human-resources) | 44% | | [Infrastructure](#infrastructure) | 33% | | [Sub processors](#sub-processors) | 10% | | [Marketing](#marketing) | 2% | | [Donations](#donations) | 1% | | Irregular expenses | 1% | | Profit margin | 4% | ## Human resources Our [small team](/us/team) consists of web developers and infrastructure engineers. Each team member needs to be able to wear multiple heads. This is how we spend our time: | Category | Share | | ----------------------- | ----: | | Maintenance | 20% | | Customer support | 20% | | Research & development | 30% | | Business administration | 20% | | Marketing | 5% | | Creative thinking :) | 5% | ## Infrastructure fortrabbit is an abstraction layer on top of AWS. Thus a lot of costs are related to the infrastructure. See [our AWS usage details](/platform/infrastructure) for more. ## Sub processors Billing, code collaboration, knowledge base, project management, support - an umbrella of different services is used to provide our customers with the service we do. See the [sub processor list](/legal/data-protection/sub-processors) for more details. ## Marketing Our marketing budget is small compared to other more marketing driven hosting providers. We currently do: - Content generation, working with external freelancers - Partnerships with software vendors ## Donations - Sponsorships for FOSS - Project Earth - Atmosfair --- - [Our AWS usage](/platform/infrastructure) # Our environmental measures Source: https://www.fortrabbit.com/environment/our-measures Published: 2026-03-15 Updated: 2026-07-19 Reviewed: 2026-07-19 > What fortrabbit does to keep its environmental footprint low: right-sized components, no over-provisioning, and no idle machines running. ## Infrastructure provider The fortrabbit is [powered by Amazon Web Services](/platform/infrastructure). Notably, Amazon is actively working towards achieving climate neutrality. By 2022 they reached 90% renewable energy across all their data centers, aiming for 100% in ~~2025~~ 2027. They also try to use less water for cooling and consume less energy in the first place. While we don't believe every word on their [sustainability marketing pages](https://aws.amazon.com/sustainability), we do hope that they use their power for good. Since prices for renewable energies are going down, there is also financial insensitive to speed this up. - [Green Web Directory](https://app.greenweb.org/directory/#1315) - externally verified ## Energy efficient design Our pricing structure is designed to enable developers to only book required resources, so we collectively consume less energy compared to traditional hosting solutions. Less over-provisioning is not only good for the wallet but also better for the environment. ## Other measures - Lean operations as a remote first company - Blocking bad bots with the Web Application Firewall - Customer education ## Not enough Comparing our carbon dioxide emissions as noted by the AWS footprint calculator with our CO2 offsetting shows that we are operating on a CO2 negative level. Too good to be true. A data center made of concrete housing large metal cages producing a lot of heat is not as green as a forest. And CO2 is not the only environmental impact here. The internet is made of routers, switches and cables. All that infrastructure requires energy too. Websites are displayed on computers that need energy too. Clouds are not green. # Reduce your website's footprint Source: https://www.fortrabbit.com/environment/your-turn Published: 2026-03-15 Reviewed: 2026-03-27 > Website obesity is real, and most performance problems are code or configuration. What a developer can do to cut a site's own footprint. [Website obesity](https://idlewords.com/talks/website_obesity.htm) is real. Most [client support](/benefits/get-support) cases are related to performance issues and in 97% of the cases it's `code/config` problem. That means the developer is not making good use of the resources. Our experience shows that there are vast differences in how much computing power is required to display a website. This includes the server computing power, bandwidth and finally how much computing is required to display a website in the browser. It mostly depends on the skills and the awareness on the subject by the web developer. Part of our work is to put a spotlight on the subject, not only by the linked pages below and personal support, but also by our XS tiers forcing the developer to do more with less. --- - [Our measures](/environment/our-measures) # How to choose the right hosting for your PHP project Source: https://www.fortrabbit.com/alternatives/how-to-choose-php-hosting Published: 2026-04-12 Updated: 2026-10-18 Reviewed: 2026-09-11 ## Why we wrote this Hosting is a lemon market: buyers cannot judge the product before they buy, so vendors compete on marketing instead of substance. Today, half of the people pushing PHP code to production are doing it with an AI coding agent, be it vibe coding or agentic engineering. That changes what "the right hosting" means. This page is the category-level version of the question. The comparisons next to it cover the providers we hear about most in evaluation calls — each with a feature table, pricing examples, and migration notes. Read this one first if the shortlist is not settled yet. ## What a PHP project needs What you need depends on code and config. A Kirby site is flat-file and needs no database. A Laravel app needs MySQL or PostgreSQL, a cache, a queue worker, and a scheduler. A Statamic site sits in between. A custom PHP app can be almost anything. - A recent PHP version (8.3 or newer) with the extensions your framework loads. - A predictable way to deploy — Git push or a CLI you can script. - Composer at build time, with a real build step. - A place to put files that survive a deploy. - TLS on a custom domain without a support ticket. Everything else — managed database, object storage, queue worker, cron — is project-specific. Match the host to your project, not to a feature checklist. ## Hosting categories, briefly Each category links to its list in [FindHost](https://www.findhost.app/), the register of hosting providers we publish. - [Shared hosting](https://www.findhost.app/categories/shared-hosting/) — cheap, isolated only at the directory level, oversold. Fine for a brochure site that nobody depends on. Not fine for anything that ships from Git, runs background jobs, or needs to stay up under load. - [VPS](https://www.findhost.app/categories/vps/) — a virtual machine with root. You become the sysadmin. Cheap on paper, expensive in hours. Only the right answer if your team has a sysadmin or your stack needs kernel-level control. - [Server management tools](https://www.findhost.app/categories/server-management/) — Laravel Forge, Ploi, RunCloud. A dashboard that provisions and configures a VPS for you. You still own the VPS, the OS upgrades, and the 3 a.m. pages. - [Vanity hosting](https://www.findhost.app/categories/vanity-hosting/) — branded resellers of someone else's infrastructure. Skip. - [Serverless](https://www.findhost.app/categories/serverless/) — functions and scale-to-zero containers that run on demand and bill per use. Bref on AWS Lambda, Cloud Run, the WASM edge. A good fit for spiky or idle workloads; more to adapt for a steady app. - [PaaS](https://www.findhost.app/categories/paas/) — Heroku, Render, Railway, Fly.io, Laravel Cloud, fortrabbit. You push code, the platform runs it. The middle ground for most PHP teams. - [IaaS](https://www.findhost.app/categories/iaas/) — AWS, GCP, Azure. Raw cloud primitives. Not hosting in the consumer sense — you assemble it yourself. - [Low-code / no-code](https://www.findhost.app/categories/lcnc/) — Lovable, Bolt, v0. AI-builder platforms that generate a frontend and host it. Useful for prototypes; not where you put a PHP app you intend to maintain. - Managed hosting — a service model rather than a category. It gets stretched to cover everything from white-glove enterprise contracts to any PaaS that does updates for you. Be specific when you compare. ## How to evaluate a provider Most "evaluation criteria" lists are uncheckable from the outside — security posture, real uptime, support quality. Stick to the things you can verify before you sign up. - PHP version is listed publicly. If a provider hides the PHP version behind a sales call, that is a red flag. - Free trial without a credit card. You should be able to deploy a real app and watch it run before you pay. - Pricing model is on the pricing page. Look for: monthly price, what happens at renewal, what happens if you cancel mid-month. Intro prices that triple on renewal are a known trap. Consumption-based or month-to-month is what you want. - Public status page with history. Not a marketing "99.99%" badge, a page showing past incidents. - Deployment is Git-push or scriptable CLI. If the only deploy path is a button in their dashboard, your CI cannot deploy and neither can your AI agent. - A real human answers support. Send a question before you sign up. If the answer is slow, generic, or written by a chatbot you cannot escape, that is what your incident response will feel like. - Documented migration path. Provider docs that explain how to move to them, and how to move off, are a sign of confidence. A few things you cannot judge from outside, and should stop pretending you can: raw NVMe throughput, OPcache hit rate on someone else's hardware, exact WAF rulesets. Benchmark numbers from marketing pages are not evidence. ## Try before you buy Deploy something. Most providers have a free tier or a trial, and an afternoon of shipping tells more than a week of comparison tables. Push the real repository rather than a hello-world — the interesting problems live in the build step, the uploaded files and the cron jobs, and none of them show up in a feature matrix. ## Let the developers pick If you are the client, or the boss, hand the decision to the people who will run the deploys. Hosting is a working environment before it is a line item, and a host picked on price by someone who never opens a terminal gets paid for twice: once on the invoice, once in the hours. ## Prefer a smaller host Smaller providers tend to be invested in one particular setup, and there is usually a person behind the support address who knows that stack. The trade is fewer regions, fewer managed extras, and a smaller company to bet on. We are one of the small ones, so weigh that as you like. ## Match the host to the project Rather than a generic decision tree, here is how we see most PHP projects line up. None of this is a hard rule. - Brochure site, low traffic, one stakeholder. Shared hosting works until you outgrow it. A PaaS free trial is usually a better starting point. - Laravel or Symfony app for a small team. PaaS. You want git-push deploys, managed MySQL, a worker, and TLS. Compare PaaS options on the [alternatives](/alternatives) page. - Custom PHP, Statamic, or Craft CMS. PaaS, ideally one that handles persistent storage natively — uploaded assets, generated images, search indexes need to survive deploys. - API backend, no frontend. PaaS or IaaS. The decision is about ops appetite rather than PHP specifics. - Agency-managed client site. PaaS with a team feature, so the agency keeps access while billing is in the client's name. - Early-stage startup. PaaS. You do not have a sysadmin and you should not hire one for this. - Traffic-growing production app. PaaS that can scale a tier or two without a re-architecture; or, if you are at scale, IaaS with someone hired to run it. - AI-builder prototype. Stay on the AI-builder host while you are prototyping. Move to a PaaS the moment you start writing real PHP — see [fortrabbit vs Lovable](/alternatives/lovable). - Vibe-coding with an AI agent. PaaS. Your agent needs an environment that is consistent, scriptable, and forgiving of mistakes. Root access on a VPS is the opposite of that. ## Pricing patterns to recognize The hosting industry runs on a handful of recurring pricing patterns. Knowing the names helps: - Intro-rate renewal. You sign up at €2 / month for the first year. Renewal is €12. Most shared-hosting and VPS-panel providers do this. Always check the renewal price before you buy. - Add-on padding. The base plan looks cheap; the database, the SSL, the backups, the email account, the migration assistant are each €5–€15 / month extras. Total the real bill rather than the headline number. - Per-unit metered without a cap. Common with polyglot PaaS and IaaS — per-second compute, per-GB egress, per-build minute. Paid upfront, the bill cannot exceed the price. Paid in arrears, the meter runs first and the ceiling is whatever happened: a loop that ran all weekend, a bot that found an expensive endpoint. A fixed plan wastes money slowly; a metered one can lose it quickly. - Term and notice period. A minimum term, a notice period and a year paid in advance are one fact — time during which money keeps leaving after the decision to leave. It is discovered late, because it is never on the pricing page next to the number. fortrabbit charges a monthly base for the app size you book, and you can cancel any month with immediate effect. There is no renewal hike because there is no fixed-term contract — see the [pricing page](/pricing) for the current matrix. ## Decision framework A short version, in order: 1. Will an AI agent or CI system deploy this? If yes, you need Git-push or scriptable deploys. PaaS. 2. Do you have a sysadmin on staff who runs Linux for a living? If yes, a VPS is on the table. If no, it is not. 3. Is this a flat-file site with no database? A PaaS free trial is still the easiest path; shared hosting is the budget alternative. 4. Do you need root access? Almost no one shipping PHP does. If you do — for a custom extension, a kernel-level dependency — you are shopping a different product category. 5. Everything else. PaaS. The question is which one. The [comparisons in this section](/alternatives) walk through fortrabbit vs the named competitors PHP teams evaluate most. ## A checklist before you commit Before you put a credit card in, confirm: - The PHP version you need is listed on a public page. - Composer and SSH access are available without an upsell. - There is a free trial you can deploy your real app on. - The pricing page shows monthly cost and what happens at renewal and on cancel. - A public status page exists, with incident history older than the current week. - The provider documents how to move your app onto the platform — and off. - Backups are described concretely, not as a marketing bullet. - Support replies to a real pre-sales question in less than a business day. ## Where fortrabbit fits We are a PHP-only PaaS, independently owned, hosted in the EU. You push code via Git, we run it. PHP version switching, Composer build, MySQL component, persistent storage, automatic TLS, staging environments, human support. Pricing is monthly and there is no renewal hike — what you book this month is what you pay next month. We are not the right answer for everyone. We do not give you root, we do not run Node services next to your PHP, and we do not host static sites you can put on a CDN for free. If you want any of those, another host is the better answer. If you are deploying PHP with an AI agent in the loop, or if you are a small team that does not want to become an ops team, [start a trial](https://dash.fortrabbit.com/signup) — no credit card required. [Start a free trial](/signup) ## Where to go next - [Compare fortrabbit against the providers you are evaluating](/alternatives) — Heroku, Cloudways, Laravel Cloud, Render, DigitalOcean, Fly.io, Railway, Lovable, Hetzner, Vultr, Laravel Forge. - [Every PHP host in the FindHost register](https://www.findhost.app/runtimes/php/) — the register we publish: filter by price, region, deployment method or shell access, described by recorded attributes rather than ranked. - [Decide if fortrabbit is for you](/solutions/you) — including who we are a bad fit for. ## FAQ ### What is the biggest mistake when picking PHP hosting? **Intro pricing** — Picking by intro price. A €2 / month plan that becomes €12 on renewal costs more than a €5 / month plan with no renewal hike, and the difference shows up a year in. Read the renewal price before you buy. ### What does a PHP project need from a host? **Four constants** — A current PHP version, Composer at build time, a scriptable deploy, and storage that survives a deploy. Database, cache, queue and cron depend on the framework: Kirby needs no database, Laravel needs several services. ### VPS vs managed PHP hosting — when does each make sense? **Sysadmin or not** — A VPS makes sense with a sysadmin on staff and a stack that needs kernel-level control. Managed PHP hosting fits everyone else. The hidden cost of a VPS is your time during the next CVE. ### Do I need root access? **No** — Almost no PHP app does. A custom extension that has to be compiled or a system daemon next to the app means you are shopping for a VPS or IaaS, which is a different product. ### Is fortrabbit a good fit for AI-assisted development? **Yes** — Git-push deploys, predictable environments, a CLI an agent can drive, and human support when the agent gets stuck. We do not give root, because an agent does not need root to deploy a PHP app. --- - [All comparisons](/alternatives) - [Is fortrabbit for you?](/solutions/you) # Arcustech alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/arcustech Published: 2026-08-14 Updated: 2026-10-18 Reviewed: 2026-09-11 ## About Arcustech Arcustech is a smaller VPS hosting company from Minneapolis, US, around since 2013. The offering includes managed and self-managed NVMe VPS hosting for Craft CMS, Statamic, WordPress, Laravel, ExpressionEngine and other PHP and MySQL applications. Data centers are in the Americas, Europe and Asia-Pacific. ## Why not Arcustech? We like Arcustech for being independent. They have a good reputation among developers and are known for their deep involvement with the Craft CMS community. You get more horse power for the penny, and on the managed line they look after the operating system. Still, the unit is a server. It gets sized upfront, and three client sites mean three servers, or one crowded box. What happens when one client's campaign goes viral on a Friday? If you really want to host on a VPS (we think you should not), consider Arcustech. ## Why fortrabbit fortrabbit is a platform built around [apps, not servers](/platform/architecture). It's more opinionated and thus offers a more streamlined DX for PHP developers who want to ship fast. A git push runs Composer and deploys, MySQL is a component, and staging is an environment next to production. We have hosted [Craft CMS](/software/craft-cms) since its early days. Independent since 2012, from Berlin. ## Arcustech and fortrabbit | Feature | Arcustech | fortrabbit | | -------------- | --------------------- | ---------------- | | Unit | Virtual server | App | | Staging | Another server | Environment | | Database | Same machine | Component | | Scaling | Resize the machine | Per component | | Regions | Americas, Europe, APAC | EU (Ireland), US | | Second project | Second server | Second app | ## FAQ ### Why use fortrabbit instead of an Arcustech VPS? **No server per project** — On a VPS a second project usually means a second server, or squeezing it onto the first. On fortrabbit a second project is a second app on the same account. ### Does Craft CMS run as well here? **Yes** — fortrabbit has hosted Craft CMS since the early days of the CMS: git push deploys with Composer in the build, migrations as post-deploy commands, and assets in persistent storage that survives deploys. ### Does fortrabbit host in the US too? **Yes** — Apps run in the EU (Ireland) or the US. Arcustech also has data centers in Asia-Pacific. If that is the requirement, they have it and we do not. --- - [All alternatives](/alternatives) - [Craft CMS hosting](/software/craft-cms) - [App hosting architecture](/platform/architecture) # AWS alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/aws Published: 2026-10-16 Updated: 2026-10-18 Reviewed: 2026-10-16 ## About AWS Amazon Web Services started in 2006 with S3 and EC2 and is the largest cloud provider by market share. It rents more than 200 services, from compute and databases to networking, billed by usage, in more than 30 regions. For a team with its own DevOps people, that range is hard to match. ## Why not AWS? AWS works by the [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/): AWS secures the cloud, the customer everything inside it. For a PHP app, that means the network, the instances or the Kubernetes cluster, the database setup, OS and PHP patches, backups, certificates, monitoring and the on-call rotation. That works for a company with a DevOps team. A marketing site or a client project rarely has one, so the responsibility lands on the developer who built the site. ## Why fortrabbit fortrabbit runs on AWS EKS, EC2, RDS, EBS and CloudFront. The PHP runtime, MySQL, backups, TLS certs and security patches are ours. When a service stops responding, a health check restarts it, and a [team is on call](/us/operations) behind that. The code stays yours: the app, CMS and plugin updates, Composer dependencies. We don't review or touch client code, as our [support policy](/benefits/get-support) states. Pricing is per component and billed after use, without a line item for NAT gateways. ## When AWS is the better choice An environment on fortrabbit runs on one instance and [scales vertically](/how-to-scale-a-php-application). The largest PHP plan has 4 GiB memory and 12 PHP processes. There is no horizontal autoscaling and no object storage. An app that outgrows this belongs on AWS directly, with someone hired to run it. ## AWS and fortrabbit | Feature | AWS | fortrabbit | | --------------- | ----------------------- | --------------------------- | | Unit | Services, assembled | Managed PHP app | | PHP runtime | DIY | Managed | | OS and patching | DIY | Managed | | MySQL | RDS, configured by you | Component | | Backups | DIY | Component | | On call | You | Us | | Scaling | Horizontal, autoscaling | Vertical, one instance | | Billing | Per service, per usage | Per component, after use | | Regions | 30+ | Ireland, Virginia | ## FAQ ### Does fortrabbit run on AWS? **Yes** — fortrabbit runs on AWS in Ireland and in Virginia. The app gets AWS hardware and network, with no AWS account to manage. ### Who restarts a service that stops responding? **We do** — Health checks restart a failed container automatically, and a team is on call behind that. Bugs in the application code stay with the developer. ### Can a Craft CMS site move from AWS? **Yes** — Create an app, import the MySQL dump through an SSH tunnel and deploy from GitHub. --- - [How we operate the platform](/us/operations) - [Infrastructure](/platform/infrastructure) - [All alternatives](/alternatives) # Cloudways alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/cloudways Published: 2026-05-12 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Cloudways Cloudways is server management software, a software service more than a full hosting service. It spins up servers on other providers, such as DigitalOcean, Vultr, Linode, AWS and Google Cloud, and patches them. Cloudways is a marketing driven hosting service with well optimized landing pages. It was acquired by DigitalOcean in 2022. We don't have first hand experience. ## Why not Cloudways? Cloudways might look like a good option for novice web developers with a tight budget. It also turns up in nearly every "best hosting" list. One reason: the affiliate program pays up to $125 per referred customer. We don't pay for recommendations. Keep that in mind when reading those lists, this page included. Take care when using server management software, there is the risk of a responsibility gap. The unit is still a server you size. When one site gets busy, the others on the same machine feel it. And a panel that once sat neutrally across clouds now belongs to one of them. ## Why fortrabbit fortrabbit is an independent hosting service with a long term commitment, bootstrapped since 2012. Our solution is more professional and more sustainable for sophisticated web developers and their clients. You pay for the app, not for a server. MySQL is a component of that app, and each app scales on its own. The people in the support chat run the platform. ## Cloudways and fortrabbit | Feature | Cloudways | fortrabbit | | ---------- | --------------------------- | ---------------------- | | Unit | Server | App | | Clouds | DO, Vultr, Linode, AWS, GCE | AWS, run by us | | Scaling | Resize the server | Per component | | Deployment | Git, SFTP, installer | git push, Composer | | Billing | Hourly per server | Per component, arrears | | Company | DigitalOcean | Independent | ## FAQ ### Are there infrastructure costs underneath a fortrabbit plan? **No** — The plan covers the PHP runtime, a MySQL component, SSL and persistent storage. There is no server to size and no separate cloud invoice. ### How does a WordPress site move from Cloudways to fortrabbit? **Code, then data** — Push the repository so Composer runs on deploy, import the MySQL dump through the SSH tunnel, and rsync the uploads into persistent storage. The move ends at DNS. ### Can a fortrabbit app be cancelled at any time? **Yes** — Cancellation runs from the dashboard with immediate effect. Billing is in arrears and pro-rated, so nothing paid upfront needs refunding. --- - [WordPress hosting](/software/wordpress) - [All alternatives](/alternatives) # Coolify alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/coolify Published: 2026-08-14 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Coolify Coolify is open-source server management software. It runs as a control panel on top of the servers you choose: Hetzner, DigitalOcean, AWS, Vultr and friends. You provision the instance, Coolify automates containers, deployments and SSL. The self-hosted edition is free without feature gates, and Coolify Cloud hosts the panel for a few dollars a month. It's one of the most-starred hosting projects on GitHub, and it earned the stars. ## Why not Coolify? It's a good fit if you want full ownership of the box and you are fine handling OS patches, backups and incident response yourself. Coolify lists available package updates, but someone has to install them. PHP on Coolify means building a Docker image: PHP version, extensions, FPM, OPcache, a worker and a cron entry. It works. It also drifts, and somebody has to own that Dockerfile when the next PHP version comes out. And you pay twice: for the server, and for the panel or your time. ## Why fortrabbit **Responsibility**: We aim for less yak-shaving. fortrabbit abstracts the plumbing and gives you a single point of contact for billing and technical questions. See our [legal section](/legal) for the boring but important bits. **App hosting**: Our platform is service oriented. You launch and scale apps, not servers. Read about our [app hosting architecture](/platform/architecture). **PHP runtime**: Tuned and version-pinned by us. No Dockerfile, and workers and cron jobs are dashboard settings. **Pricing**: You pay for the app. Entry plans fit small sites, scaling stays predictable. **Human support**: Talk to us in chat, not a bot and not a Discord thread at midnight. See our [support features](/benefits/get-support). ## Coolify and fortrabbit | Scenario | Coolify | fortrabbit | | --------------------- | --------------------------------- | ----------------- | | Full server ownership | ✅ Full control, Docker friendly | ⚠️ Opinionated | | Any language | ✅ Anything in Docker | ⚠️ PHP only | | PHP runtime | ⚠️ Build the image | ✅ Tuned, pinned | | OS updates | ⚠️ You patch, back up, monitor | ✅ Managed | | Support | ⚠️ Community first | ✅ Human support | ## FAQ ### Coolify is free. Why pay for fortrabbit? **The server is not free** — The self-hosted edition costs nothing. The server under it does, and so do off-server backups, monitoring and the hours spent on updates and incidents. fortrabbit puts the runtime, MySQL and the infrastructure in one plan. ### Who handles OS updates on fortrabbit? **We do** — OS patches, monitoring and the AWS infrastructure are our responsibility. Coolify lists available package updates, but a person has to install them. ### Can Docker images or Node.js services run on fortrabbit? **No** — fortrabbit runs PHP. A project that needs arbitrary containers or a polyglot stack on one box belongs on Coolify. --- - [All alternatives](/alternatives) - [App hosting architecture](/platform/architecture) - [Laravel install guides](/guides/laravel) # Craft Cloud alternative for Craft CMS hosting Source: https://www.fortrabbit.com/alternatives/craft-cloud Published: 2026-06-12 Updated: 2026-10-18 Reviewed: 2026-09-11 ## About Craft Cloud Craft Cloud is a relatively new hosting service by the creators of Craft CMS, Pixel & Tonic. It launched in 2024, is specialized in Craft CMS, has some fancy features and is a bit more pricey: $120 or $240 a month per project, with the Craft license included. Craft runs serverless on AWS Lambda. We like Pixel & Tonic a lot. ## Why not Craft Cloud? You may not want to put all your eggs in one basket. With Craft Cloud the CMS, the license and the hosting sit on one roadmap and one price sheet. If that sheet changes, where does the site go? Serverless also means no SSH and no disk. Commands run from a screen in the dashboard, files go to object storage. Anyone who ever fixed a Craft site late at night with `./craft`, a log file and rsync knows what that costs. ## Why fortrabbit fortrabbit is more standard, yet modern, and more flexible. The service is more open to different workflows and other software. We have been doing [Craft CMS hosting](/software/craft-cms) for a long time and know the nuts and bolts. Every app has SSH, SFTP and persistent storage. A Laravel app or a WordPress blog for the same client? Same account, same bill. fortrabbit is also more affordable. Give it a spin. See what works for you. ## Craft Cloud and fortrabbit | Feature | Craft Cloud | fortrabbit | | ------------- | --------------------- | ---------------------- | | Made by | Pixel & Tonic | Independent | | Runs | Craft CMS only | Any PHP | | Architecture | Serverless, Lambda | Persistent storage | | SSH / SFTP | No | All plans | | Craft license | Included | Bring your own | | Pricing | $120–$240 per project | Per component, arrears | ## FAQ ### Is fortrabbit cheaper than Craft Cloud? **For most sites** — Craft Cloud starts at $120 a month per project with a Craft Team license included. On fortrabbit a small Craft site with a database starts at about €5 a month, plus a license from Pixel & Tonic if the site needs one. Craft Solo is free. ### Does fortrabbit offer SSH and SFTP for Craft CMS? **Yes** — On every plan. Run craft console commands, tunnel into the database, rsync files, read logs. Craft Cloud has no SSH; commands run from a screen in its dashboard. ### Do I need my own Craft license on fortrabbit? **Yes** — Craft Cloud includes the license in its plans. On fortrabbit the license is bought from Pixel & Tonic as a one-time purchase, and it stays with the site if the site ever changes hosts. --- - [Craft CMS hosting](/software/craft-cms) - [All alternatives](/alternatives) # DigitalOcean App Platform alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/digitalocean-app-platform Published: 2026-05-12 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About DigitalOcean DigitalOcean Holdings, Inc. is a cloud company traded on the American stock market (DOCN). It started with VPS, called Droplets, and as it grew, it expanded into a broader cloud to capture a share of the larger client market. App Platform is its PaaS. DigitalOcean also acquired [Cloudways](/alternatives/cloudways). ## Why not App Platform? App Platform builds PHP with a buildpack and runs it in containers that get thrown away all the time. Anything written to the local disk is gone after the next deploy, and volumes are not supported. So the Craft CMS assets, the WordPress media library and the Laravel `storage` folder need rewiring to Spaces object storage. Forget one path and a client's images disappear on a Tuesday afternoon. Then there is the database, a separate product, and an app spec in YAML that a single PHP app never asked for. And the Droplet next door? It may seem like an affordable option, but it requires a significant investment of time and skills to set up and manage. Being a Linux sysadmin is a time-consuming job. ## Why fortrabbit Enjoy a clutter-free hosting experience. fortrabbit is not a hosting giant, but a small provider with a [track record](/us/history). We value you as a client. Every app gets persistent storage, so uploads stay where the CMS put them. MySQL is a component of the app, the PHP version is a setting, and SSH works on every plan. No YAML. ## App Platform and fortrabbit | Feature | DO App Platform | fortrabbit | | -------- | --------------------- | ------------------------- | | Runtimes | Many, buildpacks | PHP only | | Files | Ephemeral, use Spaces | Persistent storage | | MySQL | Separate product | Component | | Config | YAML app spec | Dashboard | | Company | NYSE: DOCN | Independent, bootstrapped | ## FAQ ### Do uploads survive a deploy on fortrabbit? **Yes** — Every app has persistent storage for uploads and generated files. On App Platform the local filesystem is replaced with each container, so files have to go to Spaces object storage. ### How is MySQL priced compared to App Platform? **One bill** — On App Platform the database is a separate product, from $7 for a dev database or $15.15 for managed MySQL. On fortrabbit MySQL is a component of the app, sized on its own and billed on the same invoice. ### Is there root access? **SSH yes, root no** — fortrabbit is a platform, not a VPS. Every plan has SSH and SFTP for console commands, database tunnels and file transfer; the operating system stays ours. --- - [All alternatives](/alternatives) # Fly.io alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/fly-io Published: 2026-05-12 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Fly.io Jack of all trades. Fly distributes Firecracker microVMs around the globe. Apps deploy from a Dockerfile, and registration and configuration run through Fly's CLI tool, flyctl. The CLI is comfortable and easy to use, but as complexity grows, console comfort may diminish. Billing is by usage, per second. Fly's king feature is its global distribution. If you don't require it, consider alternatives both above and below Fly. ## Why not Fly.io? Think about a typical PHP app: a Laravel shop for customers in Germany, a Craft CMS site for a museum in Amsterdam. The users sit in one country. For them the global fleet brings a Dockerfile, a `fly.toml`, the CLI and a bill made of machine seconds, volumes and bandwidth. MySQL is not offered at all. ## Why fortrabbit Like Fly, fortrabbit is a PaaS-like service. fortrabbit on the other side has a higher grade of abstraction. It's zoomed in to the specific requirements of PHP hosting: push to the branch, Composer runs, the app starts on the PHP version set in the dashboard. MySQL is a component, uploads live in persistent storage. It encourages modern paradigms, yet it is backwards compatible, with SSH and SFTP on every plan. ## Fly.io and fortrabbit | Feature | Fly.io | fortrabbit | | ------------ | ------------------ | ---------------------- | | Runtimes | Any, as microVMs | PHP only | | Deployment | flyctl, Dockerfile | git push, Composer | | MySQL | Not offered | Component | | Regions | Worldwide | EU (Ireland), US | | File storage | Volumes | Persistent storage | | Billing | Usage, per second | Per component, arrears | ## FAQ ### Does a typical PHP app need a global edge? **Rarely** — Internal tools, marketing sites and Laravel apps with one user base gain nothing from a worldwide fleet. If users are spread across continents, Fly.io's regions are a real advantage. ### Is a Dockerfile needed on fortrabbit? **No** — Push the repo, Composer runs in the build, and the app starts on the PHP version set in the dashboard. There is no image to build and no fly.toml. ### Can it be tried first? **Yes** — Seven days free per new app, no credit card. Enough to import a database and test a deploy. --- - [All alternatives](/alternatives) # Heroku alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/heroku Published: 2026-05-12 Updated: 2026-10-18 Reviewed: 2026-09-11 ## About Heroku Heroku is a rock star. It created PaaS for hosting Ruby on Rails applications, and it gave us the twelve-factor app manifesto and "git push to deploy". Then it grew and was acquired by Salesforce. So it lost momentum. The free tier went away in 2022, and the next-generation runtime is reserved for Private Spaces. Today, more modern PaaS-like providers fill the gap. [Render](/alternatives/render), [Fly.io](/alternatives/fly-io) and [Railway](/alternatives/railway) are competing for former Heroku clients. ## Why not Heroku? Heroku must make sure it can run Ruby, Java, Python, Node and whatnot, and that does not come without trade-offs. MySQL is a third-party add-on with its own account. Heroku is for enterprise clients. Does a CRM giant care about a small Laravel app? We doubt it. ## Why fortrabbit Consider fortrabbit if you are looking for a higher grade of abstraction. PHP runs in our veins. Our mission is to bring PHPower to the PHPeople. We were one of the first PHP PaaS providers (along with cloudControl and PHP Fog, both RIP) with native Composer integration. In fact, we offered PHP before Heroku did. We push for modern development and deployment practices, but treat legacy workflows respectfully. MySQL is an integrated component. Both platforms are managed, so you can focus on code instead of servers, and both deploy with git push. We are serious about hosting and yet closer to you: freelancer, digital agency and startup. So we think we can give you better support. ## Heroku and fortrabbit | Feature | Heroku | fortrabbit | | ------------ | -------------------- | ------------------------- | | Runtimes | Polyglot | PHP only | | Deployment | git push, buildpacks | git push, Composer | | MySQL | Add-on | Component | | File storage | S3 add-on | Persistent storage | | Free start | Removed 2022 | 7-day trial, no card | | Company | Salesforce | Independent, bootstrapped | ## Move from Heroku Most Heroku concepts have a counterpart. The generic steps for domains, code, uploads and DNS are in the [migration guide](https://docs.fortrabbit.com/dev/how-to/migrate-to-fortrabbit). | Heroku | fortrabbit | | -- | -- | | Procfile `web` process | PHP component, no Procfile | | Procfile `release` phase | [Post-deploy commands](https://docs.fortrabbit.com/platform/deployment/post-deploy-commands) | | `worker` dyno | [Worker job](https://docs.fortrabbit.com/platform/jobs/workers) | | Heroku Scheduler | [Cron job](https://docs.fortrabbit.com/platform/jobs/crons) | | Config vars | [Environment variables](https://docs.fortrabbit.com/platform/settings/env-vars) | | JawsDB or ClearDB add-on | MySQL component, dump [imported through an SSH tunnel](https://docs.fortrabbit.com/platform/mysql/export-import/database-up-terminal) | | Ephemeral dyno filesystem | Persistent storage, uploads survive a deploy | fortrabbit runs MySQL only. An app on Heroku Postgres switches its database to MySQL first. ## FAQ ### How long does a Laravel migration off Heroku take? **About a day** — Create the app, add a MySQL component, import the JawsDB or ClearDB dump through the SSH tunnel, paste the config vars as environment variables, and point the repo at the new app. ### Are there buildpacks? **No** — Composer runs at build time against the repo as it is. PHP version and extensions are set per environment in the dashboard. ### Is there a free tier? **A trial** — Every new app gets seven days free without a credit card. After that, billing is per component and in arrears. --- - [Laravel hosting](/software/laravel) - [All alternatives](/alternatives) # Hetzner alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/hetzner Published: 2026-05-12 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Hetzner Hetzner is an independent German web hosting company founded in 1997, headquartered in Gunzenhausen. You hear a Bavarian accent when calling their German speaking support. They offer a broad range of hosting services: shared hosting, dedicated servers, colocation, VPS, storage and cloud. Unlike the hyperscalers, Hetzner is privately held. And nobody beats them on price: a CX23 cloud server costs €5.49 a month. ## Why not Hetzner? Hetzner gives you raw infrastructure. A Linux server that you are responsible for. That means configuring the web stack, applying security patches, managing OS upgrades and monitoring uptime yourself. The low price reflects this trade-off: you pay less money but invest considerably more time. It's not only the time, it's also responsibility. Configuring servers with AI is easier than ever, but will it work, and is it secure? And who gets up at 2 a.m. when MySQL does not start again after the kernel update? ## Why fortrabbit fortrabbit is a small, independent company with a [proven track record](/us/history), also based in Germany. It is purpose-built for PHP web developers who want to ship, not administrate. The platform handles patching and uptime, a deploy is a git push away, and MySQL is a component of the app. Support is direct, not a ticket queue. Pay a bit more for the horse power and learn that you can [do more with less](/benefits/do-more-with-less). Our infrastructure runs on AWS in Ireland and the US. If a contract asks for servers in Germany, Hetzner has them and we don't. ## Hetzner and fortrabbit | Feature | Hetzner Cloud | fortrabbit | | ---------- | ------------------------------- | ----------- | | Unit | Server, root access | Managed app | | Web stack | DIY | Managed | | Patching | DIY | Managed | | MySQL | DIY | Component | | Deployment | Own scripts | git push | | Locations | Germany, Finland, US, Singapore | Ireland, US | ## FAQ ### Is fortrabbit more expensive than a Hetzner server? **About the same** — A Hetzner CX23 costs €5.49 a month, and the stack on top is yours to build. A fortrabbit app with MySQL starts at about €5 and includes the runtime, SSL, storage and the patching. ### Does fortrabbit host in Germany like Hetzner? **No** — fortrabbit is a company from Berlin, but the infrastructure runs on AWS in Ireland and in the US. If a contract demands servers in Germany, Hetzner has them and we don't. ### Which PHP stacks run on fortrabbit? **Most** — Laravel, Symfony, Statamic, Craft CMS, Kirby, WordPress and plain PHP. A stack that needs root, a daemon or a Node process next to PHP stays on a server. --- - [All alternatives](/alternatives) # Compare PHP hosting providers, fortrabbit as alternative Source: https://www.fortrabbit.com/alternatives Published: 2026-04-12 Updated: 2026-06-12 Reviewed: 2026-09-11 # Kinsta alternative for WordPress and PHP hosting Source: https://www.fortrabbit.com/alternatives/kinsta Published: 2026-09-11 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Kinsta Kinsta is a well known managed WordPress host, founded in 2013. It offers some magic to make WordPress hosting less painful and maybe a little more secure: server-level caching, staging and automatic updates. Since February 2026 Kinsta sells WordPress hosting only. Application and database hosting moved to a separate brand, Sevalla. ## Why not Kinsta? It's their WordPress, and their rules. There is a list of banned plugins, caching and backup plugins among them. Caching and backups happen the Kinsta way, or not at all. Plans are priced per site, from $35 a month. And the Laravel app for the same client now lives somewhere else. ## Why fortrabbit fortrabbit is more flexible and more open to different workflows and other software, with good support for [WordPress](/software/wordpress). fortrabbit is a good fit for more sophisticated WordPress developers. Don't expect 1-click installers or auto-updates. Enjoy more freedom and a clean separation of concerns: WordPress lives in Git, Composer pulls core and plugins on deploy, WP-CLI runs over SSH, and there is no blocklist. The Laravel API or the Craft CMS site goes on the same account. It might be mentioned that fortrabbit is more affordable than Kinsta. ## Kinsta and fortrabbit | Feature | Kinsta | fortrabbit | | ---------- | ----------------------- | ---------------------- | | Runs | WordPress only | Any PHP | | Other apps | Moved to Sevalla | Same account | | Deployment | Installer, Git over SSH | git push, Composer | | Plugins | Banned list | No list | | Updates | Managed | On push | | Pricing | From $35 per site | Per component, arrears | ## FAQ ### Does Kinsta still host non-WordPress apps? **No** — Since February 2026 application, database and static site hosting live under a separate brand, Sevalla. Kinsta sells WordPress hosting only. fortrabbit hosts any PHP app under one account. ### Can I install any plugin on fortrabbit? **Yes** — Kinsta bans plugins that conflict with its stack, such as caching and backup plugins. fortrabbit runs the plain WordPress codebase. There is no list. ### Is fortrabbit cheaper than Kinsta? **Usually** — Kinsta's single-site plan starts at $35 a month. A small WordPress site on fortrabbit starts at about €5 a month, billed in arrears. --- - [WordPress hosting](/software/wordpress) - [All alternatives](/alternatives) # Laravel Cloud alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/laravel-cloud Published: 2026-05-12 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Laravel Cloud Laravel Cloud is a service somewhere between PaaS and vanity hosting. It's made by Laravel Holdings Inc. and thus an official part of the Laravel ecosystem. The framework is free and open source. The company sells the tools around it: Forge, Nightwatch and now Cloud. In 2024 Laravel announced $57 million in funding. Laravel Cloud is a PaaS in the tradition of Heroku and, well, fortrabbit. It runs Laravel and Symfony. Plans cost $5, $20 or $200 a month plus usage, so the actual bill is a bit hard to predict. It has many advanced features, such as hibernation, autoscaling and preview environments. ## Why not Laravel Cloud? You may not want to put all your eggs in one basket. Framework, server tools, monitoring and hosting, all from one venture-funded company. Investors want their money back. - Eye-candy is maybe not that important for you - You look for backward compatibility: SSH, SFTP, a disk - Hosting budget plays a role, and your clients want a fixed quote - The Craft CMS site or the WordPress blog next door needs a home too - Ultimate scaling sounds nice, but is not a hard requirement - It's OK when your first app is up in 5, not 2 minutes ## Why fortrabbit fortrabbit is more down-to-earth. We provide a commercial hosting solution for freelancers, agencies and startups. This is our target audience, not the bycatch for the bigger fish. **Independent**: fortrabbit is bootstrapped and owner-run since 2012. We don't have to increase shareholder value. Small projects are our core business, not a marketing effort to attract big clients. **Dedicated**: Hosting is our only business, not one product out of many. **Framework agnostic**: You write PHP code, we run it. Laravel, Symfony, Craft CMS, WordPress or plain PHP, most likely without major refactoring. **Human support**: Talk directly to us using our support chat. See our [support features](/benefits/get-support). **Good Laravel support**: We have hosted Laravel for many years. There is comprehensive documentation, see our [Laravel guides](https://docs.fortrabbit.com/guides/laravel). ## Laravel Cloud and fortrabbit | Feature | Laravel Cloud | fortrabbit | | ---------- | ---------------------- | ------------------------- | | PHP apps | Laravel, Symfony | Any PHP | | SSH / SFTP | No | All plans | | Files | Object storage buckets | Persistent storage | | Regions | 9 AWS regions | EU (Ireland), US | | Pricing | $5–$200 plan + usage | Per component, arrears | | Company | Laravel Holdings, VC | Independent, bootstrapped | ## FAQ ### Does fortrabbit only run Laravel? **No** — Laravel, Symfony, Statamic, Craft CMS, Kirby, WordPress and plain PHP run on the same platform. Laravel Cloud runs Laravel and Symfony on PHP; Craft CMS, WordPress and plain PHP are not supported there. ### How does pricing compare for a small Laravel app? **Fixed vs metered** — Laravel Cloud charges a plan fee from $5 a month plus the resources the app uses while awake. fortrabbit charges fixed components per app, from about €5 a month with MySQL, billed in arrears. ### Is the code portable off fortrabbit? **Yes** — Apps run as standard PHP from a normal git repository. There is no proprietary runtime to unwind, and cancellation runs from the dashboard with immediate effect. --- - [Why not Laravel Forge?](/alternatives/laravel-forge) - [Laravel hosting](/software/laravel) - [All alternatives](/alternatives) # Laravel Forge alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/laravel-forge Published: 2026-05-11 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Laravel Forge Laravel Forge is server management software, a software service and not a hosting service. It sets up and manages servers on providers such as DigitalOcean, Hetzner or AWS, and with Laravel VPS it now rents the server too. Forge has become very good: Nginx, PHP and MySQL in minutes, zero-downtime deploys, Ubuntu security updates every week. ## Why not Laravel Forge? The server is still yours. Forge does not reboot it after a kernel patch and does not upgrade PHP or MySQL. When the Ubuntu release reaches its end of life, the advice is a new server and moving every site over by hand. You pay for two services, the server and the software. And when something breaks in between, who do you call? ## Why fortrabbit **Responsibility**: Even though we no longer handle bare metal on our own, fortrabbit offers a more conventional hosting experience. Our platform is a complete solution that abstracts the AWS infrastructure. You have one direct contact for billing and for all technical questions. See our [legal section](/legal) to see what it takes. **App hosting**: The fortrabbit platform is service oriented. Launch and scale apps, not servers. Learn about our [app hosting architecture](/platform/architecture). **Pricing**: One bill instead of two. Entry plans fit small websites. **Human support**: Talk directly to us in the support chat. See our [support features](/benefits/get-support). **Good Laravel support**: fortrabbit is around longer than Laravel Forge. We have a lot of experience hosting Laravel, and there is comprehensive documentation, see our [Laravel guides](https://docs.fortrabbit.com/guides/laravel). ## Forge and fortrabbit | Feature | Forge + server | fortrabbit | | -------------- | ---------------------- | ---------------------- | | Server | Yours, root access | Managed, no root | | Reboots | Yours | Managed | | PHP upgrades | Manual | Version switch | | OS end of life | New server, migrate | Managed | | Support | Forge, server separate | One chat | | Pricing | $12–$39 + server | Per component, arrears | Want root, Meilisearch next to the app, or someone on the team enjoys running Linux? Then Forge is the better fit. ## FAQ ### Is fortrabbit cheaper than Forge plus a server? **For small apps** — Forge starts at $12 a month and the server comes on top. A fortrabbit app with a MySQL component starts at about €5 a month. ### Do queue workers and the scheduler run on fortrabbit? **Yes** — Workers, Horizon and the scheduler run as jobs next to the web app, configured in the dashboard. ### Can spending be capped? **Yes** — Disable autoscaling and pick a fixed plan. Billing is in arrears, pro-rated, and cancellation runs from the dashboard with immediate effect. --- - [Why not Laravel Cloud?](/alternatives/laravel-cloud) - [Laravel hosting](/software/laravel) - [All alternatives](/alternatives) # Linode alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/linode Published: 2026-09-11 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Linode Linode has been one of the most dev-friendly VPS providers in the US since 2003, known for reliable Linux servers. In 2022 it was acquired by Akamai and is now sold as Akamai Cloud. The catalog talks about Kubernetes, GPUs and edge computing. The $5 Nanode survived, but who is the roadmap written for? Probably not the developer with one server and a Laravel side project. ## Why not Linode? Linode gives you a Linux server, and with it the full responsibility. Setting up and maintaining a web stack takes real time and expertise: Nginx, PHP-FPM, MySQL, certificates, firewalls. Security patches, OS upgrades and monitoring are ongoing tasks that never stop. ## Why fortrabbit fortrabbit is built for PHP web developers who want to ship, not administrate. It's a [managed PHP hosting platform](/platform/architecture) built around apps, not servers. You push code, Composer runs, and the app comes up with MySQL, SSL and persistent storage. There are no root logins and no web server configs to manage. fortrabbit is a small, independent company with a [track record](/us/history) since 2012. No acquisition, no enterprise pivot, and direct, personal support, not a ticket queue. ## Linode and fortrabbit | Feature | Linode / Akamai Cloud | fortrabbit | | ---------- | --------------------- | ----------- | | Unit | VPS, root access | Managed app | | Web stack | DIY | Managed | | Patching | DIY | Managed | | MySQL | DIY or paid service | Component | | Deployment | Own scripts | git push | | Owner | Akamai | Independent | ## FAQ ### What changed at Linode since Akamai bought it? **The audience** — Akamai acquired Linode in 2022 and sells it as Akamai Cloud. Pricing now lives on akamai.com, and the catalog grew toward Kubernetes, GPU compute and edge services. The $5 Nanode is still there. ### Is fortrabbit more expensive than a Linode? **Per month, sometimes** — A $5 Nanode is cheaper than a fortrabbit app with a database. The fortrabbit price includes the PHP runtime, MySQL, SSL, backups and the patching, and nobody's hours. ### What does a Linode still do that fortrabbit does not? **Anything outside PHP** — Node processes, system daemons, kernel tuning, GPU workloads and languages other than PHP. On fortrabbit PHP runs the app and nothing else runs next to it. --- - [Hetzner alternative](/alternatives/hetzner) - [All alternatives](/alternatives) # Lovable alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/lovable Published: 2026-05-12 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Lovable Lovable is an AI-powered builder that turns natural language descriptions into working web applications. It generates a React front end, backed by Supabase or Lovable Cloud, and publishes it with one click. It is aimed at founders and non-developers who want to move fast without hiring developers. The platform runs on a credit model: each AI interaction consumes credits. ## Why not Lovable? **You already pay for AI.** If you use Claude, ChatGPT or another assistant, those same tools write and refine application code too. **Hosting costs less when it is just hosting.** Lovable bundles hosting with its AI tooling. Separate the two, and you get a cheaper hosting bill and the freedom to switch AI tools at any time. **The prototype grows up.** Paying users, data that matters, a client asking who maintains this thing. That is the moment many teams rebuild on a stack they know. ## Why fortrabbit fortrabbit is a managed PHP hosting platform. You bring your own code, written by hand, generated by AI, or both. The code lives in your own Git repository from the start: read it, audit it, hand it to a developer, or move to another host. You get a full application stack with backend logic, a MySQL database, file storage and scheduled jobs. We run PHP only, so a Lovable project gets rebuilt in Laravel, Symfony, Craft CMS, Statamic or Kirby. An agent may write a good part of that, and that's fine. See [how agents deploy here](/workflows/vibe-coding). ## Lovable and fortrabbit | Feature | Lovable | fortrabbit | | -------- | --------------------- | ---------------------- | | Category | AI builder, hosting | Managed PHP hosting | | Output | React, Supabase | Any PHP | | Code | GitHub sync | Your repo | | Database | Postgres via Supabase | MySQL | | Pricing | Plans with credits | Per component, arrears | ## FAQ ### Can I move my Lovable project to fortrabbit? **Not as it is** — Lovable generates a React front end with a Supabase or Lovable Cloud backend. fortrabbit runs PHP only, so the project has to be rebuilt as a PHP application. ### Does fortrabbit run code written by AI agents? **Yes** — PHP is PHP, whether a person or an agent typed it. Deploys are a git push, and the CLI and docs are readable by an agent. ### What does a small PHP app cost on fortrabbit? **About €5 a month** — That covers the PHP runtime, a MySQL component, SSL and persistent storage. Billing is in arrears, and the 7-day trial needs no credit card. --- - [All alternatives](/alternatives) - [Agent ready](/workflows/vibe-coding) # Ploi alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/ploi Published: 2026-08-14 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Ploi Ploi is server management software, originally built with Laravel. It's from the Netherlands and was self-funded around 2018. One-click installs for WordPress, October CMS and others are offered. Like other tools in this category, Ploi is a control panel, not a host. You bring your own VPS, from DigitalOcean, Hetzner, Vultr, AWS and the like, and Ploi provisions and configures it for you, security updates included. That distinction is the whole story when you compare it to a managed platform. ## Why not Ploi? Ploi sets the box up, but you still own it. Backups, monitoring, full disks and the 3am incident are yours. And when something breaks, is it a Ploi problem or a provider problem? With Ploi you pay at least twice: the Ploi subscription for the panel, plus the VPS provider for the compute, often a third bill for off-server backups. Each lives in a separate account with separate support and separate invoices. ## Why fortrabbit At fortrabbit the line sits in a different place. We abstract the AWS infrastructure underneath and take responsibility for keeping it patched, monitored and running. One plan, one invoice, one place to ask for help. **Composer-first deploys**: fortrabbit deploys real PHP code via Composer. No auto-installers, so your code stays your code. **Human support**: Talk to us directly in the support chat, not a bot. See our [support features](/benefits/get-support). **Good Laravel support**: fortrabbit has been hosting Laravel apps for years, with comprehensive docs, see our [Laravel guides](https://docs.fortrabbit.com/guides/laravel). The workflows at fortrabbit are aimed more at web developers than web designers. The Ploi team also runs Ploi Cloud, a managed platform much closer to what we do. Try both, and see what works for you. ## Ploi and fortrabbit | Feature | Ploi | fortrabbit | | ----------- | ---------------- | ---------------------- | | What it is | Server panel | Managed platform | | Server | Rented elsewhere | Included | | Root access | Yes | No | | Bills | Panel + server | One | | Support | Panel only | Whole platform | | Pricing | €0–€30 + server | Per component, arrears | ## FAQ ### Is fortrabbit a control panel like Ploi? **No** — Ploi is software that manages a server rented elsewhere. fortrabbit is the hosting: there is no server to provision, code gets pushed and we run the infrastructure underneath. ### Is fortrabbit cheaper than Ploi? **Usually** — With Ploi there are at least two bills, the panel and the server provider, often a third for off-server backups. With fortrabbit there is one component plan and one invoice. ### What about Ploi Cloud? **Closer to us** — Ploi Cloud is the same team's managed platform, European, independent and PHP-first. It is a much closer comparison than the panel. Try both. --- - [All alternatives](/alternatives) - [App hosting architecture](/platform/architecture) - [Laravel install guides](/guides/laravel) # Railway alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/railway Published: 2026-05-12 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Railway Railway is a language-agnostic deployment platform, a modern take on [Heroku](/alternatives/heroku). It works for PHP, Python, Ruby, Node.js, Java and more. You get service provisioning through a futuristic looking web UI. For those who pay a bit more to run diverse workloads on polyglot stacks, Railway, [Render](/alternatives/render) or [Fly.io](/alternatives/fly-io) may be worth considering. ## Why not Railway? The bill is metered by the second: $20 per vCPU and $10 per GB of memory a month, plus egress, on top of the $5 Hobby or $20 Pro plan. Sounds fair. Now remember how PHP-FPM works: it holds its memory whether a request comes in or not. So the meter runs at 3 a.m. too, and the real number arrives when the month is over. How do you quote hosting to a client on that? ## Why fortrabbit fortrabbit is purpose-built for PHP websites and web applications. This focus makes a difference in practice: - **No config guesswork.** A curated stack tuned for PHP, web server pre-configured, extensions ready. - **No container definitions.** Deploy with git push, get logs immediately, manage everything from a clean dashboard. - **Predictable pricing.** Components with a monthly price. Month two looks like month one. - **Zoom in on your software.** [Laravel](/software/laravel), [Craft CMS](/software/craft-cms), [Kirby](/software/kirby), [Statamic](/software/statamic): install guides and tuned defaults for each. - **Human support.** Get help from the people who run the platform. See our [support features](/benefits/get-support). - **Over a decade of experience.** Serving PHP developers since 2012. See our [history](/us/history). ## Railway and fortrabbit | Feature | Railway | fortrabbit | | ------------ | ---------------------- | ---------------------- | | Runtimes | Polyglot | PHP only | | Deployment | Railpack or Dockerfile | git push, Composer | | Databases | Services, any engine | MySQL component | | File storage | Volumes | Persistent storage | | Billing | Per second | Per component, arrears | ## FAQ ### Is fortrabbit billed by usage like Railway? **No** — Each app is a set of components with a monthly price, billed in arrears. There is no per-second compute meter and no egress line. ### Can the bill be capped? **Yes** — Pick a plan and leave autoscaling off, and the invoice is the plan price. No setup fees, no annual commitment. ### What about Postgres or Redis? **Not here** — fortrabbit ships MySQL. An app that depends on Postgres needs a schema port before it moves. --- - [Laravel hosting](/software/laravel) - [All alternatives](/alternatives) # Render alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/render Published: 2026-05-12 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Render Render won Startup Battlefield at TechCrunch Disrupt SF 2019. So it's a venture backed PaaS on a mission to replace [Heroku](/alternatives/heroku). It offers a global CDN, free SSL certificates and private networks. The interface is user-friendly, including metrics graphs for network, CPU and bandwidth. The logs are easy to navigate too. ## Why not Render? Look at the list of natively supported languages: Node, Python, Ruby, Go, Rust, Elixir. PHP is not on it. PHP apps on Render run as a Docker image you build yourself. Pick a base image, install the extensions, configure PHP-FPM, Nginx and OPcache. Every PHP security release means a new image. Persistent disks are only available on paid instances. If you want to deploy and host some PHP based websites, a platform like Render is likely overkill. ## Why fortrabbit fortrabbit is also a PaaS-like service, but zoomed in to the specific requirements of fast and secure PHP hosting. The PHP version is a setting in the dashboard, Composer runs in the build, and we keep the runtime patched. MySQL is a component of the app, and storage comes with it. Don't compromise on [dev features](/features). Give fortrabbit a spin, the free trial needs no credit card. ## Render and fortrabbit | Feature | Render | fortrabbit | | ------------ | ------------------- | -------------------- | | PHP runtime | Your Docker image | Managed | | Deployment | git + Dockerfile | git push, Composer | | MySQL | Not offered | Component | | Postgres | Managed | Not offered | | File storage | Paid disk | Persistent storage | | Free start | Spins down, no disk | 7-day trial, no card | ## FAQ ### Is a Dockerfile needed on fortrabbit? **No** — Push the PHP repo and Composer runs in the build. Render has no native PHP runtime, so the Dockerfile is yours to write and maintain there. ### What about Postgres? **Plan a port** — fortrabbit ships MySQL. An app on Render Postgres needs a schema port before it moves, and for some apps that is reason enough to stay. ### Is support a person? **Yes** — Chat with the engineers who run the platform during CET business hours. No phone, not 24/7; the platform itself is monitored around the clock. --- - [Laravel hosting](/software/laravel) - [All alternatives](/alternatives) # Servd alternative for Craft CMS hosting Source: https://www.fortrabbit.com/alternatives/servd Published: 2026-08-14 Updated: 2026-10-18 Reviewed: 2026-09-11 ## About Servd Servd is a hosting service specialized in Craft CMS. It's uniquely made for Craft and has a high grade of abstraction for doing just that. Just like fortrabbit, Servd is a small hosting provider, run by an independent team in the UK. We like what they are doing over there, it's a good service. ## Why not Servd? Servd hosts Craft CMS, and only Craft CMS. But agencies rarely run one thing. There is the Craft site, a Laravel app for a client, a WordPress blog somebody inherited. On Servd only the first one has a home. SSH sessions last 24 hours by default, and changes to the filesystem are gone with the next deploy. A fair security choice, but not everyone's workflow. ## Why fortrabbit fortrabbit is also a specialized hosting service, but has a more general approach. It's thus more open for different workflows and other PHP software, such as [Laravel](/software/laravel) and even [WordPress](/software/wordpress). Compared to Servd, fortrabbit is less magic. We have hosted [Craft CMS](/software/craft-cms) since its early days. Prices with fortrabbit are generally more competitive. Servd includes staging in its plans. On fortrabbit staging is an optional environment, so you only pay for it when a project needs it. Both services are fully managed, and both are less expensive than [Craft Cloud](/alternatives/craft-cloud). Try both and see what fits you. Some prefer this, others that service. ## Servd and fortrabbit | Feature | Servd | fortrabbit | | -------------- | ---------------- | ---------------------- | | Runs | Craft CMS only | Any PHP | | Other PHP apps | No | Same account | | SSH | 24-hour sessions | All plans | | Filesystem | Reset on deploy | Persistent storage | | Staging | Included | Optional environment | | Plans | Per project | Per component, arrears | ## FAQ ### Does fortrabbit host Craft CMS as well as Servd? **Yes** — fortrabbit has hosted Craft since the early days of the CMS. Deploys run via git push with Composer in the build and migrations as post-deploy commands, and assets live in persistent storage. ### Can more than one site run on one account? **Yes** — Servd plans are picked per project. On fortrabbit several apps, Craft or otherwise, run under one account and are billed per component. ### Is fortrabbit cheaper than Servd? **Often** — Resources are picked per component rather than bundled into a tier, and billing is in arrears. A small Craft site with a database starts at about €5 a month. --- - [All alternatives](/alternatives) - [Craft CMS hosting](/software/craft-cms) - [Craft CMS guides](/guides/craft-cms) # Uberspace alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/uberspace Published: 2026-08-14 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Uberspace Uberspace is a small, service oriented, developer friendly hosting service, located somewhere between shared hosting and VPS. It's based in Germany and privacy friendly since 2010. Support is available in German too. We have heard good things about them, and they are popular with the [Kirby CMS](/software/kirby) community. Customers name their own price: €6, €9 or €12 a month are the suggestions. The German word "über" means "over". Uberspace was founded long before the taxi service Uber. ## Why not Uberspace? An Uberspace account is a shell on a shared machine. PHP, Python and Node.js run next to each other, and anything is possible. That is wonderful for tinkering. But how code arrives, how a release rolls back, where staging lives and who gets access: all of that is up to you and your shell scripts. And when a client should own the site one day, what do they get? ## Why fortrabbit fortrabbit, like Uberspace, is an indie hosting service. But the service is different. fortrabbit is more about app hosting and automation. A git push runs a Composer build and an atomic release, and staging is an environment next to production. The dashboard offers collaboration features to work with teams and clients, nobody shares a login. We offer [developer support](/benefits/get-support) through chat, also in German if required. fortrabbit is rooted in Berlin, so GDPR applies as well, but the apps run on AWS in Ireland or the US. Try it yourself, a free trial is available. ## Uberspace and fortrabbit | Feature | Uberspace | fortrabbit | | ---------- | -------------------- | ---------------------- | | Unit | Shell account | Managed app | | Runtimes | PHP, Python, Node.js | PHP only | | Deployment | Up to you | git push, Composer | | Staging | Up to you | Environment | | Location | Germany | Ireland, US | | Pricing | Pay what you want | Per component, arrears | ## FAQ ### Is Uberspace cheaper? **For one site, often** — Uberspace suggests €6 to €12 a month and lets customers pick the price. A fortrabbit app with a database starts at about €5. The math changes once a project needs a build step, staging or team access. ### Does fortrabbit host in Germany like Uberspace? **No** — fortrabbit is a Berlin company; apps run on AWS in Ireland or the US. If the requirement is German data location rather than EU jurisdiction, Uberspace has it. ### Does Kirby run on fortrabbit? **Yes** — Kirby is one of the CMS fortrabbit has hosted longest. Flat-file content lives in persistent storage that survives deploys, and content syncs over rsync. --- - [All alternatives](/alternatives) - [Kirby hosting](/software/kirby) # Vultr alternative for PHP hosting Source: https://www.fortrabbit.com/alternatives/vultr Published: 2026-05-12 Updated: 2026-09-13 Reviewed: 2026-09-11 ## About Vultr Vultr is a cloud infrastructure provider founded in 2014. They offer virtual servers, bare metal and GPU instances across a large number of data centers, billed by the hour. Vultr is known for competitive pricing on raw compute. Their target audience is developers and businesses that want full control over their infrastructure. ## Why not Vultr? Vultr gives you a Linux server and root access, and that is where the managed experience ends. Everything else is on you: installing a web server, configuring PHP, certificates, hardening, OS patches and uptime monitoring. Backups cost 20% extra, and a managed database is another product on the bill. Developers who underestimate this often end up with insecure, out-of-date servers, or spend hours on infrastructure instead of shipping features. We have seen enough PHP apps arrive from servers like that. ## Why fortrabbit fortrabbit is purpose built for PHP web developers who want to focus on code, not servers. The PHP runtime is tuned and patched by us, MySQL is a component of the app, certificates renew on their own, and a deploy is a git push with Composer in the build. There is no root, and in return the operating system stops being your problem. fortrabbit is a small, independent company with a [track record](/us/history) and direct, personal support, not a ticket queue. ## Vultr and fortrabbit | Feature | Vultr | fortrabbit | | ---------- | ---------------- | ----------- | | Unit | VPS, root access | Managed app | | Web stack | DIY | Managed | | Patching | DIY | Managed | | MySQL | DIY or paid | Component | | Backups | +20% | Component | | Locations | Worldwide | Ireland, US | ## FAQ ### Is fortrabbit more expensive than Vultr? **On the smallest tier, yes** — A small Vultr instance costs a few dollars a month. Backups add 20%, a managed database is a separate product, and the hours on the server are not on any invoice. A fortrabbit app with MySQL starts at about €5. ### Which PHP frameworks run on fortrabbit? **Most** — Laravel, Symfony, Statamic, Craft CMS, Kirby, WordPress and plain PHP. A stack that needs root, a daemon or a Node process next to PHP belongs on a server. ### How does a PHP app move from Vultr? **Push and a dump** — Push the repository to the new app, dump MySQL on the instance and import it through the SSH tunnel, rsync the uploads into persistent storage and switch the DNS. --- - [All alternatives](/alternatives) # Build the web you want to see Source: https://www.fortrabbit.com/build-the-web-you-want-to-see Published: 2026-05-06 Updated: 2026-05-09 > A hosting company telling you to own your content is selling convenience too. Here's where that tension is actually useful. fortrabbit is not really the self-hosted indie web. We run servers (on AWS), push security updates, rotate TLS certificates, and charge you for the privilege of not thinking about that. That's the same trade some big walled gardens are selling, with friendlier support and much less lock-in. If "own your content" means "depend on no one," we don't qualify. We ask you to depend on us. Between Lovable and a Raspberry Pi under your desk there's a third thing. A site that's yours — your domain, your files, your weird color choices, your eight-year-old post that nobody asked for — running on infrastructure you didn't have to build yourself. That's the web we'd like to be useful for. ## The boring parts Here's what we actually sell. Linux. PHP runtimes. TLS certificates that renew before they expire. Security patches applied on a schedule. Backups that run whether you remembered or not. Logs you can read. A deploy you don't have to babysit. None of that is glamorous. It's the part of the web nobody writes manifestos about, because nobody enjoys it. We do it so you don't have to learn it twice. That puts us closer to the cloud landlords than we'd like to admit. We try to be a smaller, more honest landlord. But we're still renting you a room. ## Own it A site we host belongs to you. Your domain. Buy it from a registrar, point it where you want, take it with you when you leave. We don't hold it. Your files. Markdown is still a joy to write and trivial to move. HTML is forty years old and still works. Static files outlive runtimes. Write in formats a future you can open without our help. Your feed. RSS still delivers posts to people who actually asked for them, no algorithm in the middle. If everything you make is exportable, portable, and addressable by a URL you control, you've already done the load-bearing work. The rest is taste. ## AI optional We're not building an AI into the dashboard. No embedded assistant, no chat widget, no autocomplete trained on your repo. Use the AI tools you prefer, or none at all. Vibe coding a weekend prototype and running a full agentic engineering setup both end the same way for us: a git push, a deploy, a site that runs. The workflow is yours to pick. ## The taste The taste is on you. A platform can host a personal site. It can't make it personal. What makes someone bookmark a stranger's blog at 1 a.m. is a posture, not a stack. It's the willingness to publish something half-finished. To pick a stubborn color palette and keep it. To write a 3,000-word essay about your favorite font. To leave the tpyo in. The web that's coming back isn't the one with the right tooling. It's the one with people in it. Odd layouts. Weird footers. Pages that take a position. We can keep the lights on. We can't be the person at the keyboard. The web is better when you show up. We'll keep the boring parts running. # Contact sales Source: https://www.fortrabbit.com/contact/sales Published: 2026-03-15 Reviewed: 2026-03-15 > Discuss project requirements, plan sizing and pricing with the people who run the platform. No sales funnel and no scripted call. fortrabbit is self service. Our website is our salesperson. Our dashboard is the point of sale. You may still have questions. Humans are here to help too. We are happy to discuss your questions and your hosting requirements with you. Whether you have specific technical needs or general inquiries about our services, we are here to help. Please have any relevant technical terms and details ready to ensure a productive conversation. We offer a free trial so you can test out our service and see how it meets your needs. Don't hesitate to reach out and explore how we can support your projects. --- - [Compliance overview](/legal/standards/compliance) # Get technical support Source: https://www.fortrabbit.com/contact/technical-help Published: 2026-03-15 Updated: 2026-07-04 Reviewed: 2026-03-27 > Where to ask a technical question about a hosted app, what to include in it, and which support channel gets an answer fastest. Please be advised to consider the points below for the best support experience and the quickest solution. ## Be on point Avoid trying to "negotiate a connection" with a support agent. We are not always ready to participate in a chat session. No need to ask how we are doing. We can not guarantee a prompt answer at all times. Describe your situation in detail and ask your questions clearly. We always answer. ## Be human There are no support bots or agents here. [We](/us/team) answer your questions. Please be human too. It's OK to work with AI. But before pasting AI slop, take steps to verify it first. ## Read, research, ask Consider the following pattern when you have a question: 1. Search and read our documentation here 2. Search the error logs, check your AI, Google and Stack Overflow 3. Haven't found answer? Ask us and provide all the details This is the most time-efficient way to handle being stuck, and it's the most respectful approach of other people's time. ## Be specific Ambiguity is the kryptonite of support. Give us timestamps, full error messages, error logs, screenshots, URLs, and any other specific information that can help to identify a problem. - Bad: _"Urgent. Something is wrong. Fix this ASAP!"_ - Better: _"At 17:00 UTC today, my app foobar shows an error: ECONNREFUSED after several seconds when I visit the URL and click the 'submit' button"_ Providing sufficient details upfront helps us respond more efficiently and effectively. We greatly appreciate when clients take the time to outline their problems thoroughly, as it reduces the need for back-and-forth communication. As a small team, minimizing chat sessions helps us manage our time better and serve you more promptly. ## Use technical terms Use technical language to describe your problem if you are able to do so. Put some effort into explaining exactly what's going on. - Bad: _"My site is stuck."_ - Better: _"When I visit mydomain.com, the browser shows an error: "Not secure" in the URL bar"_ ## Provide context We don't know your website or web application. Please provide us with the context required to understand your question. Describe your goals. ## One support ticket per issue Please don't try to speed up things by asking the same questions multiple times. We observe some times that in an urgent situation several people from the same company will initiate separate support cases. This is counter productive from our perspective. Opening multiple tickets on the same issue will only impede our ability to provide timely support. ## One issue per ticket Stick to one problem at a time, this helps reduce the noise level and confusion factor if the problem has to be handed over to another support agent. If you have a different (new) problem than the one you set out to solve initially with a support case, then please start a new conversation. Each conversation should have one topic. This helps sharpen the focus of each conversation and makes it easier to hand over a case to 2nd level support. ## Include replication steps To solve a problem we often need to recreate the scenario. Please provide us with the exact steps to replicate the issue. If we can't see it, we can't debug it. ## Ask for clarification We are often busy and usually receive a lot of questions about the same or similar topics. Sometimes we asses the situation incorrectly and provide inaccurate suggestions. If you think this has happened, or if the answer does not make sense to you, ask for explanations. Don't be afraid to correct us, or provide further details if we don't seem to understand the issue. ## Ask in English All of our support agents can speak and reply in English. ## Be kind Try to tame your temper even in stressful situations. --- - [Support policies](/legal/policies/support-policy) - [Benefit dev support](/benefits/get-support) # Feedback Source: https://www.fortrabbit.com/contact/feedback Published: 2026-03-15 Reviewed: 2026-05-15 > Suggest an idea, report a use case, or say what is missing. Product feedback goes straight to the small team that builds the platform. We are eager to learn not only from clients but also from potential clients. Your insights help us understand real-world challenges and improve our service based on actual needs. Don't be shy about reporting frustrating experiences as well. Brilliant new feature ideas are always welcome and will be discussed. Don't hesitate to reach out even if you're just evaluating - your perspective is incredibly valuable to us. We are building this for you, to stay in contact and understand you is vital for us. --- - [Recommend us](/recommend-us) # Report website down Source: https://www.fortrabbit.com/contact/website-down Published: 2026-03-15 Updated: 2026-08-23 Reviewed: 2026-04-09 > A website hosted here is not loading. First checks, what the status page shows, and how to reach support when the app stays down. Please be advised to consider the points below for the best support experience and the quickest solution. ## Keep a cool head This is an urgent situation. Please try to stay calm and focus on the facts. Emotions and allegations won't help fixing the issue. See [performance people problems](https://docs.fortrabbit.com/dev/performance/people-problems) . ## What error do you see? There are many reasons why websites go down. Often the error you are seeing in the browser gives you a good hint. There are help pages to get you started investigating these specific errors: - [403 troubleshooting guide](https://docs.fortrabbit.com/dev/http-status-codes/others/403) - [404 troubleshooting guide](https://docs.fortrabbit.com/dev/http-status-codes/404) - [500 troubleshooting guide](https://docs.fortrabbit.com/dev/http-status-codes/500) - [503 troubleshooting guide](https://docs.fortrabbit.com/dev/http-status-codes/503) - [504 troubleshooting guide](https://docs.fortrabbit.com/dev/http-status-codes/504) ## It's likely something on your side Most downtime we see is caused by "client coding mistakes" - usually by not making proper use of the available resources. In many cases we can help you to solve the issue. Many of such errors can be resolved by analyzing logs files and metrics. We are happy to discuss and research such problems together with our clients. ## It's maybe something on our side See our [status page](https://fortrabbit.betteruptime.com) if it is already known. If not, don't hesitate to contact us. Provide enough details: ## What's the context? Make sure to provide the exact app and environment names. Is the happening to just one app hosted here or to multiple or all? ## Have your developer on board We advice to get your developer in contact with us. We often can't help worried business owners if they are missing the skills to have a technical conversation about the problem. ## Have you made recent changes? Did you maybe recently pushed code? Or did some editor changed some setting on the App? Or was there any other change done, prior the downtime? Maybe someone uploaded a lot of images or performed other actions interacting with the website? Anything that can be of interest. ## Since when do you see the error? Report the exact time when the issue started to happen. ## What else do we need to to know? Is the error happening constantly, or is it more on/off? Have you got similar issues before? --- - [People problems](/dev/performance/people-problems) # Account recovery Source: https://www.fortrabbit.com/contact/account-recovery Published: 2026-03-15 Updated: 2026-04-16 Reviewed: 2026-04-16 > Locked out of a fortrabbit account? What the recovery process needs, which proof counts, and how long it usually takes to get back in. ## You have access to the email When you know the email that has been used for the account here and you have access to it: proceed by resetting the account password. This way you regain access and set a new password so that only you can login. - [dash.fortrabbit.com/recover](https://dash.fortrabbit.com/recover) - new platform - [dashboard.fortrabbit.com/recover](https://dashboard.fortrabbit.com/password) - old platform ## You don't have access to the email PROOF OF OWNERSHIP required. If you don't know the account email used or you don't have access on the email tell us details that only you — the legit owner of the business — can know. More is better: - last two digits of the current credit card in use - a previous invoice number - amount of the last invoice - name of your apps hosted here - links to LinkedIn profiles - details from conversations we have had in support - a funny commit message you can recall - a detail or a comment in the code - names and e-mail addresses of other team members - tell us the whole story why you don't have access any more - plus anything else that helps us identifying you as the real owner # Contact billing Source: https://www.fortrabbit.com/contact/billing Published: 2026-03-15 Reviewed: 2026-03-15 > Questions about an invoice, a payment, VAT or a currency: reach the billing desk and get the account looked at by a human. ### Can you send me a copy of an invoice? fortrabbit is self service. Please download invoices from the dashboard yourself. See [here](https://docs.fortrabbit.com/platform/billing/download-invoices). ### Can I pay yearly? Yearly payments are not supported because we do not accept upfront payments because the costs and the exact usage can not be predicted in advance. fortrabbit has pro-rated billing after usage. ### Why is my credit card not accepted? Sorry. We pass the data to our payment processor directly. They deal with the credit card companies to accept or reject cards. Debit cards are more likely not be accepted. Cards from countries in Asia and Africa are less likely to be accepted. ### Can I pay by PayPal? Sorry. PayPal is NOT supported. --- - [Billing docs](/platform/billing) # Vulnerability reporting Source: https://www.fortrabbit.com/contact/vulnerability Published: 2026-03-15 Reviewed: 2026-03-15 > Report a security vulnerability in the fortrabbit platform. Disclosure contact, what is in scope, and what to expect after a report. ## How to report an issue If you have discovered an issue that is not part of our out-of-scope vulnerabilities, please send an email to with the following details: - A summary of the issue and potential impact - A breakdown of the steps to replicate the issue - Details of the environment you are using - If available, any proof-of-concept code to exploit the vulnerability Upon receiving your email, our team will start investigating the issue. We will keep you updated on the progress and may reach back for further details if needed. Once the issue is resolved we will update our customers. ## Bounties - **No bug bounty** We have high regard for white hat hacking culture but there is no bug bounty program in place yet. - **No beg bounty** Don't report trivial issues such as 'SAMEORIGIN x-frame-options' or 'missing dmarc records'. ## Focus areas - Authentication bypass and privilege escalation - Exposure of personally identifiable information (PII) - Access to data outside of the authenticated workspace - SQL injection and remote command execution ## In scope - fortrabbit dashboard - fortrabbit public services - SSH environments - … ## Out of scope - Automated scanning: Scripts or tools that automatically scan for vulnerabilities are not allowed. - Social engineering: Attempts to manipulate or trick employees (including Linear employees) are strictly prohibited. - Denial of service attacks: Any activity that intentionally disrupts or overloads our systems is forbidden. - Physical access attacks: Exploiting vulnerabilities requiring physical access to a victim's computer is not permitted. - Theoretical attacks: Reporting vulnerabilities without proof of exploitability is not eligible for a reward. - Man-in-the-middle attacks: Interception of communication between users and our systems is prohibited. - Clickjacking (low-impact): Clickjacking attempts on pages with no sensitive actions (e.g., login) are not considered vulnerabilities. - Self-sabotage by privileged users: High-level users exploiting bugs to damage their own workspace does not qualify for a reward. - Logic bugs (account abuse): Exploiting bugs to bypass limitations on free accounts and access paid features is not eligible for a reward. - Security misconfigurations (informational): Identifying missing best practices in content security policy (CSP), email DNS records, or cookies may be reported but likely won't qualify for a reward. ## We kindly ask you - Responsible testing: Only test vulnerabilities on your own accounts or those for which you have explicit permission from the owner. - Respect user privacy: Avoid any actions that could violate user privacy, such as copying, destroying, or compromising data. Additionally, refrain from actions that could disrupt or degrade our service functionality. - Least privilege: If you gain authorized access to our systems, don't attempt to access additional systems or escalate your privileges beyond what's necessary. - Coordinated disclosure: If you discover a vulnerability, do not make it public before reporting it to us. This will allow us to address the issue swiftly and prevent potential exploitation. Provide us with a reasonable time frame to develop and release a fix. ## Safe harbor Activities that follow this policy are considered authorized, and we won't take legal action against you for them. If a third party sues you for actions compliant with this policy, we'll defend your compliance. ## Security hall of fame - **Mayank Bhatodra** - Salman Khan Champion - sec crew - Nils L. - Syed Khaja Faiz - [Kullai Metikala](https://twitter.com/kullai12) - Sugish Devkota # Report abuse Source: https://www.fortrabbit.com/contact/abuse Published: 2026-03-15 Reviewed: 2026-03-15 > Report illegal or harmful content hosted on fortrabbit. Where to send the report, what to include, and how quickly it is acted on. Get in touch about illegal or harmful content hosted here. We'll work with you to quickly resolve the issue. Please initially contact us by sending to this email: . ## Scope - Illegal content - Botnet activity - Login attack - Malicious activity - Child sexual abuse material (CSAM) - Copyright infringement & DMCA violations - Malware - Open service - Phishing - Spam - Trademark infringement - Violent, threatening or harassing content - Other acceptable use policy violations ## Workflow After validating a report, we will forward substantially complete abuse messages to the responsible customers. If no action is taken or if we identify repeated offenders, under appropriate circumstances, we will disable access to the content. Please include as much information as possible when submitting a report, or your request might be rejected. # Request DSAR Source: https://www.fortrabbit.com/contact/dsar Published: 2026-03-15 Reviewed: 2026-03-15 > Under GDPR and CCPA an individual can ask what personal data is stored and why, and have it corrected or deleted. How to file that request. According to GDPR and CCPA, you as an individual can require us to disclose if and what kind of data we - fortrabbit - have stored on you personally and for what purposes. You can also request to get it deleted and corrected. That's a data subject access request. Please note that fortrabbit is self service, with clients in control about most data stored. You as a client can explore, edit and delete the data we store on you in the fortrabbit dashboard yourself. Apps, teams and accounts can be deleted permanently with immediate effect. Please see the [data collection and retention page](/legal/data-protection/data-collection) to learn more about what data is stored, what for and for how long. See our [DSAR policy](/legal/data-protection/dsar-policy) also. Also, before you are sending a data erasure request, mind that we are required by German law to keep all billing related data and all business communication, like invoices and any e-mail for 10 years. Please send your DSAR request to . # Apply for sponsorship Source: https://www.fortrabbit.com/contact/sponsorship Published: 2026-03-15 Reviewed: 2026-03-15 > fortrabbit sponsors open source projects, meetups and community events in the PHP world. What gets supported, and how to apply for it. We're open to supporting projects that align with our values. As a bootstrapped company with thin profit margins, we have limited budgets, but we're happy to review qualified applications. ## Scope Projects should have some connection to: - PHP and related technologies - Open web and indie web initiatives - Environmental and social impact projects - Open source projects and tools - Community-driven initiatives - Non-profit organizations - Independent developer projects ## Out of scope - Well-funded commercial projects - Primarily commercial ventures - Individual learning or educational projects - Vague or incomplete project proposals - Political campaigns or content - Religious organizations or content ## Kind of sponsorships - Discount for fortrabbit hosting - GitHub sponsorships - … ## Requirements Pitch your project. Have appropriate track record ready to present. Link to an existing website or GitHub repo. Describe the project, your requirements and why we should sponsor it. --- - [Our culture and values](/us/culture) # Web hosting limits exceeded Source: https://www.fortrabbit.com/contact/hosting-limits-exceeded Published: 2026-03-15 Reviewed: 2026-03-15 > A website hosted here shows a limits-exceeded page. What triggers it, which component ran out, and how to get the site serving again. ## For website visitors If you see a limits exceeded error while trying to visit a website, there is unfortunately not much you can do as a visitor. You may want to inform the website owner about this issue, though this can be tricky when the site is offline. Understand that fortrabbit provides the hosting service; we are not the website owner. ## For website owners Contact your web developer or team member responsible for hosting. Log in to the dashboard, locate the affected environment, and identify which resource has exceeded its limit. You can resolve this by cleaning up unused resources, scaling up the affected component, or enabling [autoscaling](https://docs.fortrabbit.com/platform/concepts/autoscaling). Learn more about scaling and reducing usage: - [MySQL component scaling](https://docs.fortrabbit.com/platform/components/mysql#scaling) - [Web storage component scaling](https://docs.fortrabbit.com/platform/components/storage#scaling) - [Traffic component scaling](https://docs.fortrabbit.com/platform/components/traffic#scaling) You can typically resolve this quickly without support assistance. If you need help: # Service cancellation Source: https://www.fortrabbit.com/contact/service-cancellation Published: 2026-03-15 Updated: 2026-05-20 Reviewed: 2026-03-15 > How to cancel a single app, a component or the whole fortrabbit account, what happens to the data, and how the final invoice works. [Cancel your account](/cancel/account) ## Account cancellation **Remove yourself from fortrabbit.** When cancelling your account, you will remove personal access to the fortrabbit hosting system. By cancelling your account, all non-shared payment methods including all its apps will get irreversibly deleted along. Everything that is shared with other team members or clients will NOT be deleted when you cancel your personal account. When you are involved in shared teams with other members, the teams will not be deleted. You will just leave the teams. The same applies to shared payment methods and the apps that are owned by them. 1. Login to the fortrabbit dashboard, see [account recovery](/contact/account-recovery) if you don't know how 2. Go to your account overview (look for your name) 3. Find the cancel your account button 4. Read the text carefully and confirm what you are up to 5. Confirm 6. Done You will be billed one more time for the ongoing service period. ### No cancellation by email Cancellations via email or support ticket is not supported for security reasons. See the consequences and get a final chance to download recent backups. By signing in, we can verify your identity and ensure the request is legitimate. Cancelling an account can result in the permanent deletion of apps and data. The dashboard workflow includes critical warnings to prevent accidental data loss—details. ### Auto deletion of stale accounts Abandoned accounts without access to paid objects and no activity will get auto-deleted after a period of time. This is a privacy feature. ## Delete apps **Remove projects.** An app represents a website or web application. When deleting apps, all its environments and associated domains will get deleted along. Team members might lose access. Files and databases will be deleted. Costs will be billed up until the day of deletion. Make sure to take backups before deleting apps. ## Delete environments **Remove versions.** Environments are versions of websites. When environments associated domains will get deleted along. Team members might lose access. Files and databases will be deleted. Make sure to take backups before deleting environments. ## Delete teams **Delete collaboration structures.** Teams are groups of developers sharing app access. Payment methods, apps and environments that are not shared with other teams or clients will be deleted alongside, when deleting a team. Team developers will lose access to the team. Their accounts will not be deleted immediately. ## Delete payment methods **Delete unused business entities.** Make sure to review invoices, pay past due invoices if any, download previous invoices. When deleting a payment method, all the apps and attached environments it owns will be deleted alongside. Mind that the pro rated billing cycle is monthly after usage. There will be pending charges for the current month. Even after deleting the payment method one last partial invoice will be sent. --- - [Reduce hosting costs](/dev/how-to/reduce-hosting-costs) # How to scale a PHP application Source: https://www.fortrabbit.com/how-to-scale-a-php-application Published: 2026-10-13 Reviewed: 2026-10-13 > A PHP application scales by faster responses, background jobs, more PHP processes and, last, more instances. With a requests-per-second table. A PHP application scales in two directions: more PHP processes on one instance, or more instances behind a load balancer. Start with the processes. One PHP-FPM process answers one request at a time, so capacity is the number of processes divided by the average response time. Four processes at 250 ms serve 16 requests per second, the same four at one second serve 4. A faster response is therefore the cheapest scaling step, and it comes before any hardware. Second, move slow work such as mail, image transforms, and imports into background jobs, so the web processes stay free for visitors. Third, book more processes and more memory. More instances come last, because they need an app without local state: sessions, uploads, and caches have to live outside the instance. On fortrabbit an environment runs on one instance and scales vertically, so the first three steps are the ones on offer. ## Requests per second by processes and response time | Response time | 2 processes | 4 processes | 8 processes | 12 processes | | ------------- | ----------: | ----------: | ----------: | -----------: | | 100 ms | 20 | 40 | 80 | 120 | | 250 ms | 8 | 16 | 32 | 48 | | 500 ms | 4 | 8 | 16 | 24 | | 1 s | 2 | 4 | 8 | 12 | These are upper limits. Every request is assumed to take the average. A page view is often more than one PHP request, because an AJAX call or an image transform takes a process of its own. A request that arrives while all processes are busy waits in line. Aim for 250 ms or less on average. ## Scaling up with more PHP processes On fortrabbit, [managed PHP cloud hosting](/php-cloud-hosting), the PHP component sets memory and process count together: | Plan | Memory | PHP processes | Per month | | :--- | ---: | ---: | ---: | | XS | 128 MiB | 2 | €1 | | SM | 256 MiB | 2 | €2 | | MD | 512 MiB | 4 | €4 | | LG | 1 GiB | 6 | €12 | | XL | 2 GiB | 8 | €25 | | 2XL | 4 GiB | 12 | €50 | The plan is booked per environment, so staging stays small while production grows. PHP does not autoscale: processing time differs too much between apps to pick one threshold. The memory of a plan is shared by all its processes, and a request that loads too much gets a process killed. The docs [performance section](https://docs.fortrabbit.com/dev/performance) covers how to find such requests. ## Background jobs Sending mail, resizing images, and importing feeds do not belong in a web request. The [jobs component](https://docs.fortrabbit.com/platform/components/jobs) runs queue workers and cron jobs in a separate container with access to the same files and database. ## The database The [MySQL component](https://docs.fortrabbit.com/platform/components/mysql) scales separately, though it usually grows in step with PHP. Each PHP plan comes with matching MySQL connections, one per process and a few for clients from outside. A slow query holds a PHP process for as long as it runs, so read the slow queries before booking a larger plan. ## Scaling out with more instances Horizontal scaling puts the same app on several instances behind a load balancer. The price is an app that keeps nothing on local disk: sessions in a shared store, uploads in object storage, a deploy that reaches every instance. We dropped it on purpose. On our previous platform a small share of apps needed it, and the horizontally scaled stack was not much more available in practice than the single-instance one. [On horizontal scaling](https://blog.fortrabbit.com/on-horizontal-scaling) has the long version. An app that has outgrown the largest PHP component belongs on a hyperscaler, with someone hired to run it. ## FAQ ### How many PHP processes does an application need? **Peak × response time** — Multiply the PHP requests per second at peak by the average response time in seconds. At 20 requests per second and 250 ms, five processes are busy. Add headroom for the slow requests. ### Does PHP autoscale on fortrabbit? **No** — MySQL, storage, and traffic autoscale. The PHP component is booked at a fixed size and changed by hand in the dashboard, per environment. ### Does fortrabbit offer horizontal scaling? **No** — An environment runs on one instance. The PHP component scales vertically, up to the largest PHP plan. --- - [Performance](/dev/performance) - [PHP processes](/dev/performance/php-processes) - [PHP component](/platform/components/php) - [Jobs component](/platform/components/jobs) - [PHP cloud hosting](/php-cloud-hosting) # fortrabbit — managed PHP cloud hosting Source: https://www.fortrabbit.com Published: 2026-07-09 Updated: 2026-10-17 Reviewed: 2026-10-17 > Managed PHP cloud hosting since 2012. Git deploys, SSH access, managed MySQL, SSL and backups on AWS — pay-as-you-go, no lock-in. fortrabbit is [managed PHP cloud hosting](/php-cloud-hosting) on AWS for [Laravel](/software/laravel), [Craft CMS](/software/craft-cms), [WordPress](/software/wordpress), [Symfony](/software/symfony) and most other PHP software. We run the PHP runtime, MySQL, SSL certs and daily backups. A push to the [connected GitHub branch](/features/github-integration) starts a Composer build, and the release goes live once it succeeds. An app holds several environments, each with SSH and SFTP access and its own test domain, so [staging and production](/features/staging-environments) run the same code at different sizes. Apps run in Ireland or Virginia, [billed per component and per day](/pricing). fortrabbit is a bootstrapped GmbH [in Berlin](/us), operating since 2012. ## FAQ ### Who is fortrabbit for? **Developers** — Developers and agencies who build PHP websites with Git and Composer and look for managed PHP hosting. There is no control panel and no one-click installer. ### How is fortrabbit different from a server managed with Laravel Forge? **No server** — Forge sets up and manages a server that you rent. Operating system upgrades and the server bill stay with you. On fortrabbit we run the hosts, and Laravel hosting is billed per component of each environment. ### Can an AI agent work with fortrabbit? **Yes** — Coding agents such as Claude Code or Codex connect to the fortrabbit MCP server to create environments and read deploy logs. The agent skills and the CLI handle the work over SSH, such as syncing files and pulling the database. ### Can I test without a credit card? **Yes** — Every new app starts with a seven-day free trial, with all components in all sizes and no credit card. Add a payment method to keep the app after the trial. ### Does fortrabbit scale automatically? **Partly** — With autoscaling on, storage, traffic and MySQL move up to the next size once usage passes the booked one, and back down when it drops. PHP and jobs keep their booked size; change it in the dashboard. Turn autoscaling off for a fixed price. ### Can I use an external database? **Yes** — A PHP app can connect to a database from another provider, such as PlanetScale or Neon. Port 3306 is open for outgoing connections by default; open other ports in the outgoing firewall setting. A database in the same AWS region as the app keeps latency low. ### Can a client pay without developer access? **Yes** — A client account is for the person who pays. Clients see the invoices and manage billing for the apps they are added to, without access to the code. ### Can I have root access? **No** — fortrabbit is a PHP PaaS. SSH access runs in a jailed shell without root, and WebSocket connections are not supported. ### Can I cancel easily? **Yes** — Cancel the account, an app, an environment or a single component at any time in the dashboard. It takes effect immediately, and billing stops the next day. # Contract Source: https://www.fortrabbit.com/legal/contract Updated: 2026-08-24 > The contractual documents behind a fortrabbit account: terms of service, the service level agreement and the German site notice. # Service level agreement Source: https://www.fortrabbit.com/legal/contract/service-level-agreement Updated: 2026-09-13 Reviewed: 2026-09-13 > What uptime fortrabbit commits to, how it is measured, what counts as an outage, and what happens when the commitment is missed. - **99.5% general uptime** 1. fortrabbit will use commercially reasonable efforts to keep the fortrabbit platforms available at the monthly uptime percentage stated above during each billing cycle. If the guaranteed uptime is not met, you may request the service credits described in sec. 6 of this SLA. 2. Monthly uptime percentage means the total number of minutes in a billing cycle during which the fortrabbit storage system is connected to the internet and ready to send or receive information, minus the minutes of downtime in that cycle, divided by the total minutes in the billing cycle. 3. The provider may temporarily restrict access for certain internet users or user groups when required to protect network operations, infrastructure integrity, or hosted data. 4. The provider shall inform the customer in advance about all planned network operations. 5. The provider endeavors to schedule planned network operations during low-traffic periods. 6. If a service level is not met, the provider will grant service credits under the following conditions: 1. Credits are granted when the customer submits a written request (email or fax) within 10 calendar days after the end of the affected month. 2. Credits are calculated in proportion to the actual downtime relative to the total minutes in the month. 3. The total credits for all service levels in a month are capped at the monthly fee paid for the affected service. 7. Liability is governed by § 7 of the [terms of service](/legal/contract/terms). Service credits are set off against any claims for damages. --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/contract/service-level-agreement.md) # Site notice Source: https://www.fortrabbit.com/legal/contract/site-notice Updated: 2026-09-13 Reviewed: 2026-09-13 > Company details for fortrabbit GmbH in Berlin: register entry, managing directors, VAT ID and contact address, as German law requires. **Register entry** HRB 154552 B **Commercial register** Berlin (Charlottenburg) **UID (VAT IN)** DE292700027 **Authorized representatives** Frank Lämmer **Postal address** fortrabbit GmbH Glogauer Str. 24 10999 Berlin **E-mail address** **Contact point under the Digital Services Act** For authorities and users: , in German or English. Report illegal content hosted on fortrabbit via [report abuse](/contact/abuse). --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/contract/site-notice.md) # Terms of service Source: https://www.fortrabbit.com/legal/contract/terms Updated: 2026-09-13 Reviewed: 2026-09-13 > The terms of service governing a fortrabbit account: what the platform provides, what is expected in return, and how either side ends it. ## Preamble In the following, "provider" refers to fortrabbit GmbH. The provider does not recognize terms and conditions of the client that deviate from these terms in whole or in part, unless the provider has expressly agreed to them. ## § 1 Subject 1. The subject of these terms of use is the provision of data storage and computing capacity for connection to the internet (cloud web hosting platform). The client receives access to upload source code and to configure the service. 2. The services described in these terms are available only to businesses, public authorities and self-employed persons. Consumers are excluded from registration. ## § 2 Conclusion of the contract 1. The client's registration for the service offered by the provider constitutes an offer to conclude a contract. The provider then accepts or rejects this offer. Acceptance can also take place implicitly by activating the account. The provider does not permanently store the contract text. 2. Concluding the contract establishes a continuing obligation between the provider and the client. If the client books paid services, the client is obliged to pay the resulting fees at monthly intervals until the respective service is terminated. If the client uses a paid service for less than a full calendar month, the service is charged pro rata. Billing always takes place monthly in arrears. Clients paying by credit card expressly agree that their credit card is charged monthly with the recurring costs. 3. The client has no right of withdrawal. The client can, however, end the contract at any time by termination with effect for the future. ## § 3 Obligations of the provider 1. The provider ensures that the client is able to access the provider's services. ## § 4 Obligations of the client 1. If disruptions occur while using the system, the client shall inform the provider of them without undue delay. 2. The client is obliged to handle access data with care, to prevent misuse by third parties, and to inform the provider immediately if a third party has obtained unauthorized access to the client's access data. 3. The client is obliged to keep personal data up to date at all times and to update it without undue delay when it changes. 4. The client is not permitted to sublet services, unless otherwise agreed with the provider. 5. The client agrees that the provider may name the client as a reference customer in written and electronic form. 6. The client is obliged to obtain the required consent of the respective data subject insofar as the client collects, processes or uses personal data in the course of using the provider's services and no statutory permission applies. 7. The client shall back up the data transferred to the provider regularly and in a manner appropriate to the value of the data, and create own backup copies to ensure its reconstruction in case of loss. For data used in business operations, a daily backup is generally required, insofar as the data changes. In addition, before uploading data, programs and information to the services offered by the provider, the client shall check them for viruses and other malware and use state-of-the-art antivirus programs. 8. The client undertakes not to store any content on the contractual storage space, or publish it on the internet, whose provision, publication or use violates applicable law or the rights of third parties. Violations include in particular infringements of criminal law, copyright law, trademark law and the personality rights of third parties. 9. The client assures not to publish any erotic, pornographic, violence-glorifying or otherwise immoral content that is likely to impair the development of children and young people. 10. The client has a duty of care for the software the client uses, installs or programs. To protect against hacking attacks, the client updates the software in use when security vulnerabilities are known. The client undertakes to ensure that no insecure programs and scripts are used in the client's area. Operating open mail relays or similar systems through which, for example, spam e-mails can be distributed entitles the provider to disconnect the client's websites from the network immediately. The client shall inform the provider without undue delay as soon as there are indications that third parties are using the service without authorization. 11. The client undertakes to refrain from techniques that cause excessive use of the provider's facilities. 12. The client undertakes to indemnify the provider against claims of third parties of any kind resulting from the illegality of content that the client has stored on the contractual storage space. The indemnification obligation also includes the obligation to indemnify the provider against necessary legal defense costs (for example court and attorney fees). This also applies to subdomains that are registered to the provider but provided to the client. 13. If and insofar as the client uses the contractual storage space for distributing illegal content, contrary to the assurance given, the provider is entitled to block access to this content via the World Wide Web by suitable measures. 14. The [acceptable use policy](https://www.fortrabbit.com/legal/policies/acceptable-use) is part of these terms. It describes prohibited content and actions, the procedure for reporting illegal content, and how the provider handles reports. ## § 5 Remuneration and methods of payment 1. Unless otherwise agreed in writing, the current version of the price list applies ([fortrabbit.com/pricing](https://www.fortrabbit.com/pricing)). 2. Paid services are billed monthly. 3. For usage-based services, the charged traffic and storage result from the sum of all data transfers connected with the client's order (for example download, upload, website visitors). For determining traffic and storage, one gigabyte equals one thousand megabytes, one megabyte equals one thousand kilobytes and one kilobyte equals one thousand bytes. 4. If a payment is not honored (for example a returned direct debit or a credit card chargeback), the provider is entitled to charge the client the costs caused by the return as a flat €15.00. The client is entitled to prove lower damage, and the provider higher damage. 5. The provider is entitled to increase the remuneration for its services at its reasonable discretion (§ 315 BGB, German Civil Code). The provider is entitled to further increases under § 315 BGB if the last price increase was at least six months ago. The provider is obliged to inform the client of a price adjustment in advance in writing (e-mail). If the client does not agree with the price increase, the client may terminate the contract within the usual periods. 6. Invoices are issued and delivered electronically. ## § 6 Data export and switching 1. The client can export its data at any time during the term of the contract. For this, the provider offers open interfaces and their documentation free of charge, in particular Git, SSH, SFTP, database access and the API. 2. Exportable data are the data and digital assets the client has brought in or generated while using the service, in particular source code, files, databases, environment variables and environment settings. Excluded are data that relate only to the provider's operations, such as internal logs and security data, as well as data that affect the provider's trade secrets or the rights of third parties. 3. The client can request in text form to switch to another provider or to its own infrastructure, or to have all exportable data deleted (Regulation (EU) 2023/2854, Data Act). A transitional period of 30 days begins when the request is received. During that period the service continues unchanged and the provider supports the switch to a reasonable extent. If the switch is technically not feasible within that period, the provider informs the client within 14 working days, states the reasons and names an alternative period of no more than seven months. The right to terminate under § 8 remains unaffected. 4. After the transitional period, the client can retrieve its data for at least 30 more days. The provider then deletes the exportable data. The contract ends when the switch is completed successfully, and at the latest when the retrieval period ends. 5. If the client deletes an app, an environment or its account in the dashboard, this counts as an instruction to delete the affected data immediately. The periods in paragraphs 3 and 4 do not apply in that case. 6. The provider charges no switching fees for switching or for exporting data. The remuneration under § 5 for using the service during the transitional and retrieval periods remains unaffected. ## § 7 Warranty and liability 1. The provider is liable without limitation for intent and gross negligence, for damages from injury to life, body or health, where a guarantee was given, and under the Product Liability Act. 2. For a slightly negligent breach of an obligation whose fulfillment makes the proper performance of the contract possible in the first place, and on whose observance the client may regularly rely (cardinal obligation), the provider is liable only for the typical, foreseeable damage, and at most up to the monthly fee for the affected service. 3. Otherwise, liability for slightly negligent breaches of duty is excluded. 4. For the loss of data, the provider is liable only up to the effort that restoring the data would have required had the client backed it up properly (§ 4 (7)). 5. The provider bears no responsibility for service outages caused by force majeure, fault of third parties, strikes, official interventions, legal interventions, or technical or other problems outside the provider's sphere of influence. 6. The limitations of liability under paragraphs 2 to 4 also apply in favor of the provider's vicarious agents, including where claims in tort are asserted. ## § 8 Duration and termination 1. The contract is concluded for an indefinite period and can be terminated by either party by declaration in text form (§ 126b BGB). 2. The client can terminate the contract without giving reasons, with effect for the future, in the dashboard. 3. The provider can terminate the contract with a notice period of one week. 4. The right of both parties to terminate for good cause remains unaffected. 5. Good cause for termination by the provider exists in particular if the client persistently violates its obligations, or if the client fails to meet its payment obligation despite a payment reminder and a deadline. 6. Serious violations of § 4 of these terms also constitute a reason for termination without notice. ## § 9 Final provisions 1. German law applies, excluding the rules of private international law. 2. If the client is a merchant, the provider's registered office is agreed as the place of jurisdiction for all disputes arising from or in connection with this contract. 3. Should individual provisions of this contract be invalid or lose their validity due to a later circumstance, the validity of the remainder of the contract remains unaffected. 4. The provider has not submitted to any voluntary codes of conduct. 5. The contract languages are German and English. The German version is authoritative for the interpretation of these terms. --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/contract/terms.md) - [German version](https://github.com/fortrabbit/legal/blob/main/contract/terms-de.md) # Cookie policy Source: https://www.fortrabbit.com/legal/data-protection/cookie-policy Updated: 2026-09-22 Reviewed: 2026-09-22 > Which cookies the fortrabbit websites and dashboard set, what each one is for, and which of them need consent before they are placed. ## What are cookies? Cookies are text files stored on your device by a website's server. Each cookie contains a unique identifier, website's domain name, and other data to associate you. Cookies and other related measures are commonly used to track internet users across websites and devices, usually for marketing purposes. ## Cookies by fortrabbit The cookies fortrabbit sets itself on its web properties (www, docs, blog and dashboard) are functional cookies. They help to offer a convenient experience and let us recognize that you are logged in, or have set a certain color scheme. These cookies are created and used only by us and not shared with any third party. ## Advertising cookies A Google Ads remarketing tag runs on [www.fortrabbit.com](https://www.fortrabbit.com), [docs.fortrabbit.com](https://docs.fortrabbit.com) and [blog.fortrabbit.com](https://blog.fortrabbit.com). The dashboard carries no advertising tag. It sets advertising cookies, both on the `fortrabbit.com` domain and on Google's own domains, so that fortrabbit ads can be shown to the same browser on other websites. The tag is not loaded for visitors in jurisdictions that require opt-in consent for advertising cookies — the EEA, the UK, Switzerland, Brazil and Quebec. It is also not loaded when the location is unknown, or when the browser sends a Global Privacy Control signal. The location is determined from the IP address via MaxMind. Where the tag loads, Google can set these cookies: | Cookie | Domain | Duration | Purpose | |--------|--------|----------|---------| | `_gcl_au` | `fortrabbit.com` | 90 days | Links an ad click to a later visit | | `_gcl_aw` | `fortrabbit.com` | 90 days | Stores the click ID of an ad click | | `IDE` | `doubleclick.net` | up to 13 months | Shows ads to the same browser on other websites | | `test_cookie` | `doubleclick.net` | 15 minutes | Checks whether the browser accepts cookies | The durations are Google's defaults. Opt-out routes are listed on the [privacy page](/benefits/privacy). Ad click parameters in the URL, such as `gclid` and `utm_source`, are passed from www to the signup page in the link itself. fortrabbit stores them in no cookie. ## Cookies by fortrabbit sub-contractors Certain functionalities of our services are not provided by us directly, but integrated via a third party. This includes but is not limited to: - Git provider - Payment processing - Support chat - Status page These services are storing their own cookies and have their own respective policies. We aim to make the usage of these third-party integrations optional where possible and make it visible wherever a third-party service is used. ## How to delete cookies? You can restrict or block cookies through your browser settings. ## Contacting us If you have questions about this policy, please contact us, see [fortrabbit.com/contact](https://fortrabbit.com/contact). --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/data-protection/cookie-policy.md) # Data collection and retention Source: https://www.fortrabbit.com/legal/data-protection/data-collection Updated: 2026-09-23 Reviewed: 2026-09-23 > Which data fortrabbit stores during hosting operations, how long each type is kept, and what customers can erase for themselves. fortrabbit stores various types of data during hosting operations to perform relevant business functions. For some of this data fortrabbit clients have full control about erasure, other data needs to be kept for a longer period. Retention periods depend on the different types of data stored. If a law enforcement request, legal obligation or business need requires it, data may be retained longer than the original purpose as described here. ## Dashboard data The data stored in our client database is only accessible for individual clients protected by username/password login. ### Account Client account data containing information on name, e-mail, geo location, usage and more is retained for as long as the account is active. Clients can erase associated data by deleting their account with the fortrabbit dashboard. fortrabbit may keep anonymized hints on pre-existing Accounts to keep track of historic events. Accounts are deleted automatically when the e-mail address is not verified within 14 days, when onboarding is not finished 17 days after signup, or 12 months after an account was marked idle because it has no team, payment method or app access. Idle accounts receive a warning e-mail one week before deletion. If an account was created after an ad click or a campaign link, the click ID, the campaign parameters and the signup button used are stored with it. Every account also records how it was created: directly, through an invitation to a team, to an app, as a client or for billing, or by import from the previous platform. These fields are kept as long as the account exists. For accounts with a click ID, conversion data is sent to Google, see [section 10 of the privacy statement](/privacy-statement). The record of those uploads is deleted after 90 days and with the account. ### Teams In the fortrabbit dashboard, there are teams, consisting of team members. They can also be deleted directly with the fortrabbit dashboard. ### Payment methods Payment information is stored with payment methods, which are associated with apps and accounts, in the fortrabbit dashboard, and thus can be deleted by our customers. ### Invoices Invoices, including the receiver's name, postal address and e-mail, are kept for 10 years in accordance with German tax laws. ## Support chat Client support communications between fortrabbit and our clients is deleted when an a account is deleted. ## App data Apps are containers where clients can store various types of data including files, databases and a Git repository. Apps can also be deleted by clients through the fortrabbit Dashboard. All App-associated data is deleted shortly after the App is deleted from the Dashboard. ## Logs You can interact with fortrabbit services on various transport protocols. We store connection data in log files with each access. This may include the request time, the IP address of the client, protocol details, URL called, response status, the number of bytes transferred, a referrer-url and the web user-agent (browser and OS). We are doing so for security reasons — to avoid malicious and unauthorized access. We reserve the right to analyze and block certain IPs from our services based on these access logs. Certain log parts might kept for analysis and fraud protection. In any event, we do not store client IP addresses or access data for more than 30 days. ### System level logs System level logs, such as SSH access and connection logs are securely stored in our infrastructure and are not accessible to clients. They are maintained by fortrabbit for security reasons. Such logs are not accessible to clients and are retained for no more than 30 days. They may contain IP addresses or App names used by clients or website visitors. ### App level logs Application logs are secured behind key-based or password-based SSH access so that only clients have access to individual logs. These log files can not be edited by clients. They are retained with the App, so if the App gets removed these logs will be removed as well. We do not impose specific life-time limitations or these logs. We do not control or remove any log files that the App creates by itself. #### Web access logs The web server access logs contain IP addresses of the visitors to the Apps. #### PHP error logs The PHP error logs contain information on runtime exceptions, allowing developers to debug their application code. ## Backups Backups (if booked) for active Apps have a schedule and a retention period as stated with the documentation of the backups. Remaining backups are deleted within an hour after the environment is deleted. ## Additional emergency snapshots We may keep internal snapshots of environments for disaster recovery on a best-effort basis. There is no guarantee that a snapshot exists. Snapshots are not accessible to clients and are kept for no more than 30 days. ## Data disclosure We do not disclose client data to third parties unless legally obligated to do so. The exception is the ad conversion data described in [section 10 of the privacy statement](/privacy-statement). ## Sub-processor data sharing Please visit our [sub-processors page](/sub-processors) to learn more about the data shared with third-party vendors. ## Data breach notification We have internal procedures in place to deal with data breaches on our side. Once a data breach notification is ready and approved internally, we will inform affected clients - as soon as possible and with as much detail as possible. ## Data subject access You as an individual can request us to disclose if and what kind of data we have stored on you personally and for what reason. Please visit our [DSAR page](/dsar-policy) for more details. --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/data-protection/data-collection.md) # Data processing agreement Source: https://www.fortrabbit.com/legal/data-protection/data-processing Updated: 2026-09-13 Reviewed: 2026-09-13 > The data processing agreement between fortrabbit and its customers: scope, obligations, sub-processing and the technical measures in place. ## 1. Introduction, scope, definitions 1. This contract is concluded between the customer of fortrabbit GmbH, hereinafter referred to as "client", and fortrabbit GmbH, hereinafter referred to as "contractor". It supplements every existing hosting contract between the contractor and the client, hereinafter also referred to as the "main contract", when the client processes personal data on the hosting platform of the contractor. Within its scope, it takes precedence over the main contract. 2. This contract governs the rights and obligations of client and contractor, hereinafter referred to as the parties. 3. This contract applies to all activities in which employees of the contractor or subcontractors commissioned by it (subcontractors) process personal data of the client. 4. Terms used in this agreement shall be understood as defined in the EU General Data Protection Regulation. Insofar as declarations have to be made in the following "in writing", the written form according to § 126 BGB is meant. Incidentally, declarations may also be made in other forms insofar as adequate verifiability is ensured. ## 2. Subject and duration of processing 1. The contractor provides web hosting services. The client receives the possibility to process data: save, modify, transmit, delete. The client receives access to the web space and databases. The activity of the contractor is limited to the provision of this IT infrastructure. 2. Processing starts from the date on which the client makes use of the services and shall continue for an indefinite period until termination of this contract or the main contract by a party and the subsequent final deletion of any personal data. ## 3. Purpose of the data processing 1. The client processes data for its own purposes. He is not obliged to disclose the purpose of the processing to the contractor. 2. The client alone is responsible for the type and structure of the data. The contractor has no influence on the type of data and the circle of those affected. ## 4. Obligations of the contractor 1. The contractor processes personal data exclusively as contractually agreed or as instructed by the client, unless the contractor is legally obliged to perform certain processing. If such obligations exist for him, the contractor shall inform the client of these prior to processing, unless the communication is prohibited by law. In addition, the contractor uses the data provided for processing for no other, especially not for own purposes. 2. The contractor confirms that he is aware of the relevant general data protection regulations. He observes the principles of proper data processing. 3. The contractor undertakes to strictly observe confidentiality during processing. 4. Employees who are able to obtain knowledge of the data processing must undertake in writing to maintain confidentiality, insofar as they are not already subject to a relevant secrecy obligation by law. 5. The contractor warrants that the persons involved in the processing have been made familiar with the relevant provisions of data protection and this contract before the start of processing. Appropriate training and awareness-raising measures should be repeated regularly. The contractor shall ensure that persons employed for the processing of orders are regularly adequately instructed and monitored with regard to the fulfillment of data protection requirements. 6. If the client is subject to inspection by supervisory authorities or other bodies or if data subjects assert rights against him, the contractor undertakes to support the client to the extent necessary, insofar as the processing on the order is concerned. 7. The contractor may only provide information to third parties or the data subject with the prior consent of the client. He will immediately forward inquiries directed to him to the client. 8. If required by law, the contractor shall appoint a competent and reliable person as data protection officer. It has to be ensured that there are no conflicts of interest for the commissioner. In cases of doubt, the client can contact the data protection officer directly. Changes in the person or the internal tasks of the representative shall be communicated by the contractor to the client without delay. 9. Order processing takes place within the EU or the EEA as well as on data processing equipment of the company Amazon Web Services, partly in the USA. Any transfer to a third country may only take place with the consent of the client and under the conditions set out in Chapter V of the General Data Protection Regulation and in compliance with the provisions of this contract. With respect to the above-described use of Amazon Cloud, consent is given upon conclusion of the contract. Transfers to the USA are based on the European Commission's adequacy decision for the EU-US Data Privacy Framework (Implementing Decision (EU) 2023/1795) where the recipient is certified under it, and otherwise on the European Commission's standard contractual clauses (Art. 46 para. 2 lit. c GDPR). ## 5. Technical and organizational measures 1. The data security measures described at [www.fortrabbit.com/legal/standards/security-measures](https://www.fortrabbit.com/legal/standards/security-measures) are determined to be binding. 2. They define the minimum owed by the contractor. The description of the measures must be made in such detail that it is clear to a knowledgeable third party at any time, solely on the basis of the description, what the required minimum should be. 3. A reference to information that can not be obtained directly from this agreement or its annexes is not permitted. 4. The data security measures can be adapted to the technical and organizational development as long as the agreed level is not undershot. 5. The contractor must implement without delay any changes necessary to maintain information security. 6. Changes are to be communicated to the client immediately. 7. Significant changes are to be agreed between the parties. 8. Insofar as the security measures taken do not or no longer meet the requirements of the client, the contractor shall inform the client immediately. 9. The contractor warrants that the data processed in the order will be strictly separated from other data. 10. Copies or duplicates are not made without the knowledge of the client. Excluded are technically necessary, temporary reproductions, as far as an impairment of the here agreed data protection level is excluded. 11. The contractor will provide regular proof of fulfillment of its obligations under the website [www.fortrabbit.com/legal/standards/security-measures](https://www.fortrabbit.com/legal/standards/security-measures), in particular the full implementation of the agreed technical and organizational measures. ## 6. Rules for the correction, deletion and blocking of data 1. Data processed in the context of the order will only be corrected, deleted or blocked by the contractor in accordance with the contractual agreement or the instructions of the client. 2. If the client permanently violates his contractual obligations, the contractor is entitled to delete the client's Account. In this case, all data will be deleted. The client is informed in advance of this measure. 3. The contractor will comply with the client's instructions at any time and beyond the termination of this contract. ## 7. Subcontracting 1. The contractor employs the following subcontractor: Amazon Web Services. 2. The commissioning of further subcontractors is permitted, the subcontractors are to be notified in writing to the client prior to the beginning of the data processing. The client can reject subcontractors. 3. All subcontractors shall be subject to at least data protection obligations that are comparable to those agreed in this contract. Upon request, the client will be given access to the relevant contracts between contractor and subcontractor. 4. The rights of the client must also be exercised effectively against the subcontractor. In particular, the client must be entitled to carry out inspections at subcontractors at any time, to the extent specified here, or have them carried out by third parties. 5. The responsibilities of the contractor and the subcontractor must be clearly differentiated. 6. Subcontracting by the subcontractor is permitted. Paragraphs 2 to 5 apply, mutatis mutandis. 7. The contractor shall carefully select the subcontractor with special regard to the suitability of the technical and organizational measures taken by the subcontractor. 8. The forwarding of data processed in the order to the subcontractor is only permitted if the contractor has documented that the subcontractor has completely fulfilled his obligations. The client can inspect the documentation. 9. Contracting subcontractors who do not carry out on-order processing exclusively from the territory of the EU or the EEA is only possible if the conditions set out in Chapter 4 of this contract are observed. In particular, it is only permissible if and as long as the subcontractor offers adequate data protection guarantees. 10. The contractor will inform the client on request, which concrete data protection guarantees the subcontractor offers and how proof of this can be obtained. 11. Subcontractors listed on the website [www.fortrabbit.com/legal/data-protection/sub-processors](https://www.fortrabbit.com/legal/data-protection/sub-processors), hereinafter referred to as the Transparency Page, at the time of signing the contract, will comply with the terms and conditions of the contractor accepted. 12. The contractor reserves the right to employ new subcontractors or to replace subcontractors. 13. The contractor publishes changes in subcontractor relations on the transparency page. 14. The client has the option to track changes on GitHub. The address is: [https://github.com/fortrabbit/legal/blob/main/data-protection/sub-processors.md](https://github.com/fortrabbit/legal/blob/main/data-protection/sub-processors.md). 15. If the client does not agree with a new subcontractor, the right to immediate termination exists. 16. Subcontracting relationships within the meaning of this contract are only those services that have a direct connection with the provision of the main service. 17. Additional services such as transport, maintenance and cleaning as well as the use of telecommunication services or user services are not included. 18. The obligation of the contractor to ensure compliance with data protection and data security in these cases remains unaffected. ## 8. Rights and obligations of the client 1. The client alone is responsible for the assessment of the admissibility of the commissioned processing as well as for the protection of the rights of those concerned. 2. The client issues all orders, partial orders or instructions in documented form. In urgent cases, instructions can be given orally. The client confirms such instructions in documented form without delay. 3. The client is entitled to check, to an appropriate extent, the contractor's compliance with data protection regulations and the contractual agreements, either itself or through third parties, in particular by obtaining information, by inspecting the stored data and the data processing programs, and by other on-site checks. 4. The contractor grants the persons entrusted with the check access and insight as far as necessary. 5. The contractor is required to provide the necessary information, to demonstrate procedures and to provide the evidence required to carry out an inspection. 6. Inspections of the contractor shall be carried out without avoidable disruption of his business operations. 7. Unless otherwise indicated for urgent reasons to be documented by the client, controls shall take place after reasonable advance notice and during business hours of the contractor, and not more frequently than every 12 months. 8. Insofar as the contractor provides evidence of the correct implementation of the agreed data protection obligations as stipulated in chapter 5.6 of this contract, a check shall be limited to random samples. ## 9. Notification requirements 1. The contractor immediately informs the client of personal data protection breaches. Also justified suspicions on this are to be communicated. The notification must be made at the latest within 24 hours after the contractor's knowledge of the relevant event to an address specified by the client. It must contain at least the following information: 1. the name and contact details of the data protection officer or other contact point for further information; 2. a description of the likely consequences of the violation of the protection of personal data; 3. a description of the actions taken or proposed by the contractor to remedy the breach of personal data protection and, where appropriate, measures to mitigate their potential adverse effects. 2. Immediate notification of any major problems in the execution of the order as well as breaches by the contractor or persons employed by him against data protection regulations or the stipulations made in this contract. 3. The contractor shall immediately inform the client of any inspections or measures by supervisory authorities or other third parties, insofar as these relate to order processing. 4. The contractor undertakes to support the client in the scope of its obligations pursuant to Art. 33 and 34 of the General Data Protection Regulation. ## 10. Instructions 1. The client himself has full access to the data at all times, so that it is not necessary for the contractor to cooperate, in particular also for correction, blocking or deletion. 2. Where the co-operation of the processor is required, the processor shall be obliged to reimburse the reasonable costs incurred. In this case, the person responsible has a comprehensive right to issue instructions on the type, scope and procedure of data processing pursuant to Art. 29 i.V.m. 28 DSGVO too. 3. The processor must inform the controller without delay if he believes that an instruction violates data protection regulations. The processor shall be entitled to suspend the execution of the relevant instruction until it has been confirmed or changed by a person authorized to do so by the person responsible. 4. Authorized by the client to issue instructions are all persons with a fortrabbit account, who are registered with the company of the client as an employee. With every directive, the employee will have to legitimize himself. 5. All employees of the contractor are trained and authorized to receive instructions. ## 11. Termination of the contract 1. Upon termination of the contract, the data will be destroyed. 2. Any existing copies of the data will also be destroyed upon expiry of the retention period, if such exists. The destruction must take place in such a way that it is no longer possible to recover even residual information with justifiable effort. 3. The contractor is obliged to bring about the immediate return or deletion also with subcontractors. ## 12. Liability 1. The contractor is liable in principle only for its own fault. 2. A liability of the contractor for slightly negligent breaches of duty is excluded, as far as damages from the injury of the life, the body or the health or guarantees are concerned or claims according to the product liability law are not affected. 3. Furthermore, the liability for the breach of obligations, the fulfillment of which enables the proper execution of the contract in the first place and on whose observance the customer may regularly rely (cardinal obligations) remains unaffected. 4. The above limitation of liability applies regardless of the legal grounds of liability and also in favor of employees and vicarious agents of the contractor. 5. A duty of compensation of the contractor against the client is excluded, as far as the damage was caused by the correct implementation of the commissioned service or an instruction given by the client. ## 13. Special right of termination 1. The client may terminate the main contract and this agreement at any time without notice ("extraordinary termination") in the event of a serious breach by the contractor of data protection regulations or the provisions of this agreement, the contractor can not or will not execute an instruction from the client or the contractor refuses inspection rights of the client in breach of contract. 2. A serious breach shall, in particular, exist if the contractor has not materially fulfilled or has not fulfilled the obligations specified in this agreement, in particular the agreed technical and organizational measures. 3. In the case of insignificant infringements, the client shall set a reasonable deadline for the contractor to remedy the situation. If the remedy does not occur in time, the client is entitled to extraordinary termination as described in this section. ## 14. Other 1. Both parties are obliged to confidentially treat all knowledge of business secrets and data security measures of the respective other party obtained in the course of the contractual relationship as regards the termination of the contract. 2. If there are any doubts as to whether the information is subject to confidentiality, it must be treated as confidential until written approval by the other party. 3. If the client property is endangered by measures taken by third parties (such as seizure or confiscation), insolvency or settlement proceedings or other events, the client must inform the contractor immediately. 4. The written form is required for side agreements. 5. The plea of retention i. P. V. § 273 BGB is excluded with regard to the data processed in the order and the associated data carrier. 6. Should individual parts of this agreement be ineffective, this does not affect the validity of the agreement otherwise. --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/data-protection/data-processing.md) - [German version](https://github.com/fortrabbit/legal/blob/main/data-protection/data-processing-de.md) # Data subject access requests policies Source: https://www.fortrabbit.com/legal/data-protection/dsar-policy Updated: 2026-09-13 Reviewed: 2026-09-13 > How fortrabbit handles data subject access requests: who may ask, what is disclosed, which deadlines apply and how identity is verified. ## Please note See how to get in touch [to query about your personal data here](/contact/dsar). ## 1. Right to information 1. You may ask us to confirm if personal data concerning you is processed by us. 2. If such processing is available, you can request information about the following information: 1. the purposes for which the personal data are processed; 2. the categories of personal data that are processed; 3. the recipients or the categories of recipients to whom the personal data relating to you have been disclosed or are still being disclosed; 4. the planned duration of the storage of your personal data or, if specific information is not available, criteria for determining the duration of storage; 5. the right of rectification or deletion of personal data concerning you, a right to restriction of processing by the person responsible or a right to object to such processing; 6. the existence of a right of appeal to a supervisory authority; 7. all available information on the source of the data if the personal data are not collected from the data subject; 8. the existence of automated decision-making including profiling under Article 22 (1) and (4) GDPR and - at least in these cases - meaningful information about the logic involved, and the scope and intended impact of such processing on the data subject. 3. You have the right to request information about whether the personal data concerning you are transmitted to a third country or to an international organization. In this connection, you can request the appropriate guarantees in accordance with Art. 46 GDPR in connection with the transfer. 4. In the case of data processing for scientific, historical or statistical research purposes: This right of access may be restricted to the extent that it is likely that the realization of the research or statistical purposes is impossible or seriously impaired and the restriction is necessary for the performance of research or statistical purposes. ## 2. Right to rectification 1. You have a right to request the controller to rectify and / or complete your data, if your personal data is incorrect or incomplete. 2. You can correct many data yourself as a registered and registered client. Incidentally, the responsible person must make the correction without delay. 3. In the case of data processing for scientific, historical or statistical research purposes: Your right of rectification may be limited to the extent that it is likely to render impossible or seriously affect the realization of the research or statistical purposes and the restriction is necessary for the performance of the research or statistical purposes. ## 3. Right to restriction of processing 1. Under the following conditions, you may request the restriction of the processing of your personal data: 1. if you deny the accuracy of your personal information for a period of time that enables the controller to verify the accuracy of your personal information; 2. the processing is unlawful and you refuse the deletion of the personal data and instead demand the restriction of the use of the personal data; 3. the person responsible no longer needs the personal data for the purposes of the processing, but you need them for the assertion, exercise or defense of legal claims, or 4. if you have objected to the processing pursuant to Art. 21 (1) GDPR and it is not yet certain whether the legitimate reasons of the person responsible prevail over your reasons. 2. If the processing of personal data concerning you has been restricted, these data may only be used with your consent or for the purpose of asserting, exercising or defending legal claims or protecting the rights of another natural or legal person or for important reasons such as the public interest of the Union or of a Member State. 3. If the restriction of processing according to the aforementioned preconditions is applied, you will be informed by the person in charge before the restriction is lifted. 4. In the case of data processing for scientific, historical or statistical research purposes: Your right to restriction of processing may be limited to the extent that it is likely to render impossible or seriously affect the realization of the research or statistical purposes and the restriction is necessary for the performance of research or statistical purposes. ## 4. Right to cancellation ### 1. Obligation to delete 1. You may require the controller to delete the personal information concerning you without delay and the controller shall immediately erase that information provided that any of the following is true: 1. The personal data concerning you are no longer necessary for the purposes for which they were collected or otherwise processed. 2. You revoke your consent, to which the processing acc. Art. 6 para. 1 lit. a or Art. 9 para. 2 lit. DSGVO and there is no other legal basis for processing. 3. You place acc. Art. 21 para. 1 DSGVO objection to the processing and there are no prior justifiable reasons for the processing, or you lay gem. Art. 21 para. 2 DSGVO Opposition to processing. 4. Your personal data have been processed unlawfully. 5. The deletion of personal data concerning you is required to fulfill a legal obligation under Union law or the law of the Member States to which the controller is subject. 6. The personal data concerning you were collected in relation to information society services offered pursuant to Art. 8 (1) GDPR. ### 2. Information on third parties 1. If the person responsible has made the personal data relating to you public and is in accordance with Article 17 (1) of the GDPR, it shall take appropriate measures, including technical means, to inform data controllers who process the personal data that you have been identified as being affected, taking into account available technology and implementation costs, that you have requested the deletion of all links to such personal data or of copies or replications of such personal data. ### 3. Exceptions 1. The right of erasure does not exist if the processing is necessary: 1. to exercise the right to freedom of expression and information; 2. to fulfill a legal obligation required by the law of the Union or of the Member States to which the controller is subject, or to carry out a task which is in the public interest or in the exercise of official authority delegated to the controller; 3. for reasons of public interest in the field of public health pursuant to Art. 9 (2) lit. h and i and Art. 9 (3) GDPR; 4. for archival purposes of public interest, scientific or historical research purposes or for statistical purposes acc. Article 89 (1) GDPR, to the extent that the law referred to in subparagraph (a) is likely to render impossible or seriously affect the achievement of the objectives of that processing, or 5. to assert, exercise or defend legal claims. ## 5. Right to information 1. If you have asserted the right of rectification, erasure or restriction of the processing to the controller, the latter is obliged to notify all recipients to whom your personal data have been disclosed of this correction or deletion of the data or restriction of processing unless this proves to be impossible or is associated with a disproportionate effort. ## 6. Right to data portability 1. You have the right to receive personally identifiable information relating to you provided to the controller in a structured, common and machine-readable format. You also have the right to transfer this data to another person without hindrance by the person responsible for providing the personal data, provided that: 1. the processing on a consent acc. Art. 6 para. 1 lit. a GDPR or Art. 9 para. 2 lit. a DSGVO or on a contract acc. Art. 6 para. 1 lit. b DSGVO is based and 2. the processing is done using automated procedures. 2. In exercising this right, you also have the right to obtain that personal data concerning you are transmitted directly from one person responsible to another person responsible, as far as this is technically feasible. Freedoms and rights of other persons may not be affected. 3. The right to data portability does not apply to the processing of personal data necessary for the performance of a task in the public interest or in the exercise of official authority delegated to the controller. ## 7. Right to object 1. You have the right at any time, for reasons arising from your particular situation, to prevent the processing of your personal data, which pursuant to Art. 6 para. 1 lit. e or f DSGVO takes an objection; this also applies to profiling based on these provisions. 2. The controller will no longer process the personal data concerning you unless he can demonstrate compelling legitimate grounds for processing that outweigh your interests, rights and freedoms, or the processing is intended to assert, exercise or defend legal claims. 3. If the personal data relating to you are processed for direct marketing purposes, you have the right to object at any time to the processing of your personal data for the purpose of such advertising; this also applies to profiling insofar as it is associated with such direct mail. 4. If you object to processing for direct marketing purposes, your personal data will no longer be processed for these purposes. 5. Regardless of Directive 2002/58 / EC, you have the option, in the context of the use of information society services, of exercising your right to opt-out by means of automated procedures that use technical specifications. 6. In the case of data processing for scientific, historical or statistical research purposes: You also have the right, for reasons arising from your particular situation, to process personal data relating to you for scientific or historical research purposes or for statistical purposes. Art. 89 para. 1 GDPR is to be contradicted. Its right of objection may be limited to the extent that it is likely to render impossible or seriously affect the realization of the research or statistical purposes, and that the restriction is necessary for the performance of the research or statistical purposes. 7. You can object to the use of your data for advertising at any time by e-mail to , including the transmission of conversion data to Google. We then delete the click ID and campaign data from your account and send no further conversion events for it. ## 8. Right to revoke the data protection consent declaration 1. You have the right to revoke your data protection consent declaration at any time. The revocation of consent does not affect the legality of the processing carried out on the basis of the consent until the revocation. ## 9. Automated decision on an individual basis including profiling 1. You have the right not to be subject to a decision based solely on automated processing - including profiling - that will have legal effect or similarly affect you in a similar manner. This does not apply if the decision: 1. is required for the conclusion or performance of a contract between you and the controller, 2. is permitted by Union or Member State legislation to which the controller is subject, and where such legislation contains appropriate measures to safeguard your rights and freedoms and legitimate interests, or 3. has your express consent. 2. However, these decisions may not be based on specific categories of personal data under Art. 9 (1) GDPR, unless Art. 9 (2) lit. a or g DSGVO applies and reasonable measures have been taken to protect the rights and freedoms as well as your legitimate interests. 3. With regard to the cases referred to in (1) and (3), the person responsible shall take reasonable measures to uphold the rights and freedoms as well as your legitimate interests, including at least the right to obtain the intervention of a person by the person responsible Position and contesting the decision. 4. fortrabbit makes no decisions based solely on automated processing, including profiling, that have legal or similarly significant effects. Showing ads to a browser through remarketing is not such a decision. ## 10. Right to complain to a supervisory authority 1. Without prejudice to any other administrative or judicial remedy, you shall have the right to complain to a supervisory authority, in particular in the Member State of its place of residence, employment or the place of the alleged infringement, if you believe that the processing of your personal data violates the GDPR. 2. The supervisory authority to which the complaint has been submitted shall inform the complainant of the status and results of the complaint, including the possibility of a judicial remedy pursuant to Article 78 of the GDPR. --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/data-protection/dsar-policy.md) - [German version](https://github.com/fortrabbit/legal/blob/main/data-protection/dsar-policy-de.md) # Data protection Source: https://www.fortrabbit.com/legal/data-protection Updated: 2026-08-24 > How fortrabbit handles personal data: privacy statement, data processing agreement, sub-processors, cookies and data subject requests. # Privacy statement Source: https://www.fortrabbit.com/legal/data-protection/privacy-statement Updated: 2026-09-23 Reviewed: 2026-09-23 > What personal data fortrabbit collects, why it is processed, which third-party services are involved, and which rights apply under GDPR. ## 1. Scope of this statement This is the privacy statement required by German law for interacting with our websites. In the following, "websites" refers to the internet addresses `www.fortrabbit.com`, `docs.fortrabbit.com`, `blog.fortrabbit.com`, `dash.fortrabbit.com`, `api.fortrabbit.com` and `mcp.fortrabbit.com`, as well as `dashboard.fortrabbit.com` and `help.fortrabbit.com` of the previous platform. This statement covers usage from unregistered website visitors as well as registered clients. ## 2. Name and address of the responsible The legally responsible, hereinafter also "we" or "our", within meaning of the General Data Protection Regulation and other national data laws of the member states as well as other data protection regulations, is: fortrabbit GmbH Glogauer Str. 24 10999 Berlin ## 3. General information about data processing ### 1. Scope of processing of personal data 1. In principle, we process personal data of our users only insofar as this is necessary to provide a functional website and our content and services. 2. The processing of personal data of our users takes place regularly only with the consent of the user. 3. An exception applies in cases in which prior consent is not possible for actual reasons and the processing of the data is permitted by law. ### 2. Legal basis for the processing of personal data 1. Insofar as we obtain the consent of the data subject for processing of personal data, Art. 6 para. 1 lit. a EU General Data Protection Regulation (GDPR) as legal basis. 2. In the processing of personal data necessary for the performance of a contract of which the data subject is a party, Art. 6 para. 1 lit. b DSGVO as legal basis. This also applies to processing operations required to carry out pre-contractual actions. 3. If processing of personal data is required to fulfill a legal obligation that is subject to our company, Art. 6 para. 1 lit. c DSGVO as legal basis. 4. In the event that vital interests of the data subject or another natural person require the processing of personal data, Art. 6 para. 1 lit. d DSGVO as legal basis. 5. If processing is necessary to safeguard the legitimate interests of our company or a third party and if the interest, fundamental rights and freedoms of the data subject do not prevail over the first interest, Art. 6 para. 1 lit. f DSGVO as legal basis for processing. ### 3. Data deletion and storage duration 1. The personal data of the data subject shall be deleted or blocked as soon as the purpose of the storage is removed. 2. It may also be stored if provided for by the European or national legislator in EU regulations, laws or other regulations to which the controller is subject. 3. A blocking or deletion of the data takes place if the storage period, prescribed by the standards mentioned, expires, unless there is a need for further storage of the data for a contract or fulfillment of the contract. ## 4. Providing the website and creating log files ### 1. Description and scope of data processing 1. Whenever our website is accessed, our system automatically collects data and information from the computer system of the computer making the request. 2. The following data is collected here: information about the browser type and the version used, the user's operating system, the IP address of the user, the date and time of access, websites from which the user's system accesses our website, websites which are accessed by the user's system through our website. 3. The data is also stored in the log files of our system. ### 2. Legal basis for data processing 1. The legal basis for the temporary storage of data and log files is Art. 6 para. 1 lit. f DSGVO. ### 3. Purpose of the data processing 1. The temporary storage of the IP address by the system is necessary to allow delivery of the website to the computer of the user. To do this, the user's IP address must be kept for the duration of the session. 2. Storage in log files is done to ensure the functionality of the website. 3. In addition, the data is used to optimize the website and to ensure the security of our information technology systems. 4. The log files are not evaluated for marketing purposes. Advertising is covered in sections 5 and 10. 5. In these purposes, our legitimate interest in the processing of data accords with Art. 6 para. 1 lit. f DSGVO. ### 4. Duration of storage 1. The data will be deleted as soon as they are no longer necessary for the purpose of their collection. 2. In the case of the collection of data for the provision of the website, this is the case when the respective session is completed. 3. In the case of storing the data in log files, this is the case after no more than 30 days, unless legal or technical reasons or the need for security make longer storage necessary. 4. Further storage is possible. 5. In this case, the IP addresses of the users are deleted or alienated, so that an identification of the calling client is no longer possible. ### 5. Removal possibility 1. The collection of the data for the provision of the website and the storage of the data in log files is essential for the operation of the website. 2. There is consequently no contradiction on the part of the user. ## 5. Use of cookies ### 1. Description and scope of data processing 1. Our websites use cookies. Cookies are text files that are stored in the browser on the user's computer system. When a user visits a website, a cookie may be stored on the user's operating system. 2. This cookie contains a characteristic string that allows the browser to be uniquely identified when the website is reopened. 3. We use cookies to make our website more user-friendly. Some elements of our website require that the calling browser be identified even after a page break. 4. The cookies store and transmit data such as currency, session and account information, selection in ordering systems, CSRF tokens and potentially other metadata. ### 2. Legal basis for data processing 1. The legal basis for storing cookies in the browser and accessing them is § 25 para. 2 no. 2 TDDDG (German Telecommunications Digital Services Data Protection Act), insofar as they are strictly necessary for using the websites. 2. The legal basis for the subsequent processing of personal data is Art. 6 para. 1 lit. f GDPR. 3. The support chat (Intercom) loads only when it is opened. Visitors outside the USA who are not logged in give their consent first. In that case, the legal basis is § 25 para. 1 TDDDG and Art. 6 para. 1 lit. a GDPR. ### 3. Purpose of the data processing 1. The purpose of using technically necessary cookies is to facilitate the use of websites for users. 2. Some features of our website can not be offered without the use of cookies. 3. For this it is necessary that the browser is recognized even after a page break. 4. For these purposes, our legitimate interest in the processing of personal data is pursuant to Art. 6 para. 1 lit. f DSGVO. ### 4. Duration of storage, objection and disposal options 1. Cookies are stored on the computer of the user and transmitted by this on our side. 2. Therefore, as a user, you have full control over the use of cookies. 3. By changing the settings in your internet browser, you can disable or restrict the transmission of cookies. 4. Already stored cookies can be deleted at any time. 5. This can also be done automatically. 6. If cookies are disabled for our website, not all features can be fully used. ### 5. Advertising cookies 1. For visitors outside the EEA, the UK, Switzerland, Brazil and Quebec, `www.fortrabbit.com`, `docs.fortrabbit.com` and `blog.fortrabbit.com` load a Google Ads remarketing tag. It sets advertising cookies so that Google can show fortrabbit ads to the same browser on other websites. The individual cookies are listed in the [cookie policy](https://www.fortrabbit.com/legal/data-protection/cookie-policy). 2. The tag is not loaded in the regions named, when the location is unknown, or when the browser sends a Global Privacy Control signal. The location is determined from the IP address of the current request via MaxMind. 3. The legal basis is Art. 6 para. 1 lit. f GDPR. Our legitimate interest is advertising our services. 4. The dashboard loads no advertising tag. ## 6. Registration ### 1. Description and scope of data processing 1. On our website, we offer users the opportunity to register by providing personal information. 2. The data is entered into an input mask and transmitted to us and stored. 3. When the user signs in with GitHub, GitLab or Google, that provider transmits the name, e-mail address and profile picture. 4. To prevent fraudulent registrations, the IP address is sent to MaxMind to determine the location (country, region, city). This location and the date and time of registration are stored, the IP address itself is not. 5. Further recipients, for example for payment processing and support, are named in the [list of sub-processors](https://www.fortrabbit.com/legal/data-protection/sub-processors). 6. If the user arrives through an ad or a campaign link, the Google Ads click ID (`gclid`), the campaign parameters (`utm_source`, `utm_medium`, `utm_campaign`, `utm_term`, `utm_content`) and the signup button used are stored with the account. These values are not stored in a cookie. During a sign-in with GitHub, GitLab or Google, they are held briefly in the browser's session storage. 7. The account also records how it was created: directly, through an invitation to a team, to an app, as a client or for billing, or by import from the previous platform. ### 2. Legal basis for data processing 1. The legal basis for the processing of the data is Art. 6 para. 1 lit. b GDPR, as the registration serves pre-contractual measures or the performance of a contract to which the user is a party. 2. The legal basis for determining the location is Art. 6 para. 1 lit. f GDPR. Our legitimate interest is preventing fraudulent registrations. 3. The legal basis for storing the campaign data and how the account was created is Art. 6 para. 1 lit. f GDPR. Our legitimate interest is measuring the success of advertising and invitations. ### 3. Purpose of the data processing 1. User registration is required for the provision of certain content and services on our websites. In the case of registration for free trial offers, registration is required for the prevention of abuse. 2. Registration of the user in connection with the ordering of paid services is required to fulfill a contract with the user or to carry out pre-contractual measures. ### 4. Duration of storage 1. The data will be deleted as soon as they are no longer necessary for the purpose of their collection. 2. This is the case during the registration process for the performance of a contract or for the performance of pre-contractual measures if the data are no longer necessary for the performance of the contract. 3. Even after conclusion of the contract, there may be a need to store personal data of the contracting party in order to comply with contractual or legal obligations, the latter in particular according to HGB and the tax law. ### 5. Opposition and removal possibility 1. As a user, you have the option of canceling the registration at any time. You can change the data stored about you at any time. 2. If the data are necessary for the fulfillment of a contract or for the execution of pre-contractual measures, a premature deletion of the data is only possible, as far as non-contractual or legal obligations preclude a deletion. ## 7. Product information ### 1. Description and scope of data processing 1. We inform registered clients by e-mail about changes that affect the service, such as scheduled maintenance, new releases and security-relevant changes. 2. In addition, we send hints on using the account, such as reminders to finish the setup. 3. The e-mails are sent via Postmark, occasional product announcements also via MailChimp. For this, the e-mail address, the name and the content of the message are transmitted. 4. The data are used exclusively for sending these messages. ### 2. Legal basis for data processing 1. The legal basis for messages concerning the contract is Art. 6 para. 1 lit. b GDPR. 2. The legal basis for hints on using the account is Art. 6 para. 1 lit. f GDPR. Our legitimate interest is supporting clients in using the service. ### 3. Purpose of the data processing 1. The e-mail address is processed to deliver these messages. ### 4. Duration of storage 1. The data will be deleted as soon as they are no longer necessary for the purpose of their collection. The e-mail address of the user is therefore (like all contract-related data) stored as long as the client maintains an active user account. ### 5. Opposition and removal possibility 1. Hints on using the account can be unsubscribed in the account settings in the dashboard. 2. Messages required for the performance of the contract cannot be unsubscribed. Storage of the e-mail address ends when the account is deleted. ## 8. E-mail contact ### 1. Description and scope of data processing 1. It is possible to contact the provided e-mail address. 2. In this case, the user's personal data transmitted by e-mail will be stored. 3. The data is used exclusively for the processing of the conversation. ### 2. Legal basis for data processing 1. Legal basis for the processing of the data is in the presence of the consent of the user Art. 6 para. 1 lit. a GDPR. The legal basis for the processing of the data transmitted in the course of sending an e-mail is Article 6 (1) lit. f DSGVO. If the e-mail contact aims to conclude a contract, then additional legal basis for the processing is Art. 6 para. 1 lit. b DSGVO. ### 3. Purpose of the data processing 1. In the case of contacting by e-mail, this also includes the necessary legitimate interest in the processing of the data. ### 4. Duration of storage 1. The data will be deleted as soon as they are no longer necessary for the purpose of their collection. 2. For the personal data sent via e-mail, this is the case when the respective conversation with the user has ended. 3. The conversation ends when it can be inferred from the circumstances that the relevant facts have been finally clarified. 4. Statutory regulations, such as the obligation to store business mail, may preclude premature cancellation. ### 5. Opposition and removal possibility 1. The user has the opportunity to revoke his consent to the processing of personal data at any time. 2. If the user contacts us by e-mail, he may object to the storage of his personal data at any time. 3. In such a case, the conversation can not continue. ## 9. Data collection by third party companies We are using third party sub processors to improve our service offerings. That might also include sharing some personal data. See a list of services in use and their application here: [fortrabbit.com/legal/data-protection/sub-processors](https://www.fortrabbit.com/legal/data-protection/sub-processors) Some of these services are based in the USA. Transfers there are based on the European Commission's adequacy decision for the EU-US Data Privacy Framework where the recipient is certified under it, and otherwise on the European Commission's standard contractual clauses (Art. 46 para. 2 lit. c GDPR). For persons in Switzerland, the Swiss-US Data Privacy Framework applies accordingly. ## 10. Transmission of conversion data to Google ### 1. Description and scope of data processing 1. For accounts with a stored Google Ads click ID, we transmit conversion data to Google Ads once a day. The transmission runs directly from server to server, regardless of the account's region. 2. Transmitted are the click ID, the time of registration and, after the first payment, the time of that payment with a fixed conversion value. Each event carries an identifier made of the event type and the fortrabbit account ID. 3. Name, e-mail address, billing data and app data are not transmitted. 4. Only events within 90 days of registration or of the first payment are transmitted. ### 2. Legal basis for data processing 1. The legal basis is Art. 6 para. 1 lit. f GDPR. ### 3. Purpose of the data processing 1. The transmission measures which ads lead to registrations and paying accounts. This is our legitimate interest. 2. Google processes the data under the Google Ads Data Processing Terms. For the transfer to the USA, section 9 applies. ### 4. Duration of storage 1. The click ID and campaign data are stored as long as the account exists. 2. The record of which events were transmitted (account ID, event type, time) is deleted after 90 days and with the account. ### 5. Opposition and removal possibility 1. The user can object to the transmission at any time by e-mail to . 2. We then delete the click ID and campaign data from the account and transmit no further events. ## 11. Rights of data subjects See [fortrabbit.com/legal/data-protection/dsar-policy](https://www.fortrabbit.com/legal/data-protection/dsar-policy). --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/data-protection/privacy-statement.md) - [German version](https://github.com/fortrabbit/legal/blob/main/data-protection/privacy-statement-de.md) # Sub-processors Source: https://www.fortrabbit.com/legal/data-protection/sub-processors Updated: 2026-09-22 Reviewed: 2026-09-22 > Every third-party service fortrabbit uses, what it processes and why. Sub-processors are assessed for security and GDPR, with DPAs in place. All of our sub-processors have been assessed for security and GDPR compliance. Enacted contract amendments and Data Processing Agreements (DPAs) are in place where applicable. The following third party services transparency report gives you an overview which external services we use, how and why. ## Infrastructure & data centers The fortrabbit platform runs on **Amazon Web Services** (AWS). That includes our websites (www, docs, blog and dash) and the apps our clients create here. Various different services from AWS (EC2, RDS, S3, Route53, Cloudfront, etc) are used in combination. See [AWS Service Terms](https://aws.amazon.com/service-terms). - Apps will be stored in the data center location you choose. - Billing related and Account data is stored in Ireland. ## Payment processing Credit card billing information is stored with our credit card payment processor **Stripe** directly. In addition we also provide Stripe with your zip code to ensure correct authorization. Stripe might also store your IP and user agent data collected from your browser. We only keep a minimum of information on our side: a reference and an identifier. SEPA bank account information is stored with our databases. Terms available on request. ## Usage and performance statistics We use a tool to see track visits called **Fathom**. This covers all web properties and is configured cookie-less. We use **New Relic** to monitor errors and performance of our backend. Error reports may contain request data. New Relic is not loaded on the websites and sets no cookies. ## Advertising We run a **Google Ads** remarketing tag on [www.fortrabbit.com](https://www.fortrabbit.com), [docs.fortrabbit.com](https://docs.fortrabbit.com) and [blog.fortrabbit.com](https://blog.fortrabbit.com), and not in the dashboard. The tag is loaded only for visitors in jurisdictions that do not require opt-in consent for advertising cookies. It is not loaded when the location is unknown or when the browser sends a Global Privacy Control signal. Google receives the fact that a browser opened one of these pages, together with the IP address and user agent that request carries, and uses it to show fortrabbit ads to the same browser on other websites. The tag itself shares no account, billing or app data. See the [Google Ads Data Processing Terms](https://business.safety.google/adsprocessorterms) and [how Google uses data from sites that use its services](https://policies.google.com/technologies/partner-sites). Opt-out routes are listed on our [privacy page](/benefits/privacy). Separately, a nightly job sends conversion data to **Google Ads** server to server, for accounts created after an ad click and regardless of region: the click ID, the signup time, the time of the first payment with a fixed value, and an identifier made of the event type and the fortrabbit account ID. No name, e-mail address, billing or app data is sent. See [section 10 of the privacy statement](/legal/data-protection/privacy-statement). ## Client communication In order to help you successfully deploy and manage your applications here, we need to be able to communicate with you. In most cases we will use chat or contact you by e-mail. ### Support service Our support chat is powered by **Intercom**. This service collects some meta-data, like browser, operating system and geo-location when you interact and provide your name and e-mail to get in touch with us. For logged-in accounts, the name, e-mail address and an account ID are shared via API. This helps us giving you a personal and fast support. In general the support channel is chat, but it is not limited to that. The help desk is also employed when you write an e-mail to "" and possibly other addresses. Sometimes our answers in the support desk might be delivered by e-mail to make sure they'll reach you. When you delete your account with fortrabbit, the connected data-set will also get deleted. Intercom analyzes your usage using cookies to "improve service" and "enhance user experience". They collect publicly available contact and social information and share it with their partners. For more info on privacy practices, visit the [Intercom Privacy](https://www.intercom.com/terms-and-policies#privacy) and see the [Intercom Terms](https://www.intercom.com/terms-and-policies#terms). ### Product information subscription We may use **MailChimp** to send occasional e-mail updates on service changes and feature announcements. For this, e-mail addresses and names are exported to MailChimp. Each of these e-mails includes a one-click opt-out. We write from "". See [MailChimp Terms](https://mailchimp.com/legal/terms). ### Personal e-mails We are required by law to store all business communication for ten years. So we will save your e-mails, when you contacts us by e-mail. Our personal mail (MX) accounts are by **Google** (gSuite). See [gSuite Terms](https://gsuite.google.com/terms/standard_terms_checkout.html). ### Transactional e-mails We use **Postmark** to send automated transactional e-mails to Accounts. These e-mails include relevant information. They are either triggered by intervals or user interaction. Examples are: "double opt-in sign-up", "invoice notice", "trial expire notice" or "password reset". Naturally, there is no opt-out for these. Again, that's why you need to confirm that you are willing to be contacted by e-mail when signing up. We will write from "". See [Postmark Terms](https://postmarkapp.com/terms-of-service). ## Status updates Downtimes and incidents are published on [status.fortrabbit.com](https://status.fortrabbit.com), a status page provided by **Better Stack**. The status indicator on the fortrabbit websites loads its data from Better Stack, which receives the visitor's IP address with that request. See the [Better Stack privacy policy](https://betterstack.com/privacy). ## Recruitment software We use may use 3rd party software to manage our hiring processes, to evaluate and track applicants. If you apply for a job here, consider the privacy from the 3rd party provider. ## Account meta data At signup, the IP address is sent to **MaxMind**, which returns a geo-location (country, region, city). The geo-location and the signup time are stored with the account, the IP address is not. This helps against fraudulent signups and phishing. ## AI tools The team uses **Claude** by **Anthropic** for coding and internal work. When it helps with a support case or a ticket, Claude can read the chat conversation or ticket content, which may contain names, e-mail addresses and app names. Anthropic is based in the USA. See our [AI usage policy](/legal/policies/ai-usage-policy) and the [Anthropic privacy policy](https://www.anthropic.com/legal/privacy). ## Internal case management We use **Linear** as an internal ticketing system to keep track of ongoing business tasks. We might link client cases from the chat system or other details such as app names there as well. See [Linear privacy](https://linear.app/privacy). ## Account profile pictures Accounts that sign in with **GitHub**, **GitLab** or **Google** receive name, e-mail address and profile picture from that provider. The profile picture is shown in the dashboard. Pictures of fortrabbit team members on the websites are loaded from **Gravatar**, which receives the visitor's IP address. No customer e-mail hashes are sent to Gravatar. ## Accounting We employ a tax agency called **Ecovis**, as well as potentially other accountants to help us with financial accounting. Naturally, these service providers have reading access to billing related data and invoices. Billing related data, like invoices, are stored with **Google Drive** (Google Apps for Business). ## Embedded content In certain cases we might embed content from other web services in our websites. This can be a hotlink, some JS, or an iframe. Examples are a **YouTube** video, or a poll by **Google forms** or just an image from another website. Of course, this might contain your IP and a timestamp as well. ## Content Delivery Network The websites of the current platform serve their static assets themselves, without a third-party CDN. ## Website screenshots The dashboard shows screenshots of client apps. They are created by **Urlbox**, which periodically loads the default domain of an environment. ## Knowledge base We document internal standard procedures in a knowledge base. In some cases it references client data, such as extra settings or individual agreements. The knowledge base is a private Git repository hosted on **GitHub**. ## Code hosting Your Git code base is hosted on **GitHub**. We connect to through our fortrabbit GitHub app. ## FOSS In addition to all the useful commercial services listed above, fortrabbit would not be possible without free and open-source software. We make use of thousands of different open-source software packages. ## Disclaimer To err is human. We do our best to keep this page up-to-date, complete and correct. We reserve the right to add, change or remove certain services and practices without further announcement. --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/data-protection/sub-processors.md) # Legal Source: https://www.fortrabbit.com/legal Updated: 2026-08-24 > Terms of service, privacy statement, data processing agreement, sub-processor list and platform policies, all collected in one place. # Acceptable use policy Source: https://www.fortrabbit.com/legal/policies/acceptable-use Updated: 2026-09-13 Reviewed: 2026-09-13 > What may and may not be hosted on fortrabbit. The platform is for websites, web applications and web APIs; this policy lists the exceptions. Make fair use of this. This document outlines what is not allowed here. fortrabbit is intended to be used to host websites, web applications, and web APIs. This policy describes forbidden uses. The examples described here are not exhaustive. We may modify this policy at any time. ## Prohibited content It is not allowed to use, encourage, facilitate, promote or instruct others to use the services for any illegal, harmful, fraudulent, infringing or offensive use, or to transmit, store, display, distribute or otherwise make available "evil" content. This includes: * **Illegal or harmful**: Illegal contents, that violate the rights of others, or that may be harmful to others' reputation, including disseminating, promoting or facilitating child pornography, offering or disseminating fraudulent goods, promotions, make-money-fast schemes, ponzi and pyramid schemes, phishing, pharming, crypto-currency mining or brokering, gambling or anything even loosely supporting the before mentioned topics. * **Infringing**: Content that infringes or misappropriates the intellectual property or proprietary rights of others. * **Harmful**: Content or other computer technology that may damage, interfere with, surreptitiously intercept, or expropriate any system, program, or data, including trojan horses, cancelbots, viruses, worms, time bombs, Facebook friend bots. * **Offensive**: Content that is defamatory, obscene, abusive, invasive of privacy, or otherwise objectionable, including content that constitutes child pornography, relates to bestiality, or depicts non-consensual sex acts. * **Grey area**: We are aware that there are many business types that are not illegal but questionable. Examples are medical marijuana, dating, fake download websites, SEO farms. If your business is in such a grey area, contact us upfront. ## Prohibited actions It is not allowed to use the services to violate the security or integrity of any network, computer or communications system, software application, or network or computing device. This includes: * **Interception**: Monitoring of data or traffic on a computer system without permission. * **Unauthorized access**: Accessing or using any system without permission, including attempting to probe, scan, or test the vulnerability of a computer system or to breach any security or authentication measures. * **Origin falsification**: Forging TCP-IP packet headers, e-mail headers, or any part of a message describing its origin or route. The legitimate use of aliases and anonymous remailers is not prohibited by this provision. It is also not allowed to make network connections to any users, hosts, or networks without permission to communicate. This includes: * **Monitoring or crawling**: Monitoring or crawling of a computer system that impairs or disrupts the computer system being monitored or crawled. * **Denial of service (DoS)**: Inundating a target with communications requests so the target either cannot respond to legitimate traffic or responds so slowly that it becomes ineffective. * **Intentional interference**: Interfering with the proper functioning of any System, including any deliberate attempt to overload a system by mail bombing, news bombing, broadcast attacks, or flooding techniques. * **Operation of certain network services**: Operating network services like open proxies, open mail relays, or open recursive domain name servers. * **Avoiding system restrictions**: Using manual or electronic means to avoid any use limitations placed on a system, such as access and storage restrictions. ## Prohibited messaging It is not allowed to distribute, publish, send, or facilitate the sending of unsolicited mass e-mail or other messages, promotions, advertising, or solicitations (SPAM), including advertising and informational announcements. It is not allowed to alter or obscure mail headers or assume a sender's identity without the sender's explicit permission. It is not allowed to collect replies to messages sent from another internet service provider if those messages violate this policy or the acceptable use policy of that provider. ## Quota and limits The fortrabbit platform has certain soft and hard limits. Hard limits are automatically enforced by the service. Soft limits are consumable resources that you agree not to exceed. ## Monitoring and enforcement We reserve the right, but do not assume the obligation, to investigate any violation of this policy. In consequence we may: remove, disable access, or even modify content; report any activity that we suspect violates any law or regulation to appropriate law enforcement officials, regulators, or other appropriate third parties. This reporting may include disclosing appropriate client information. ## Reporting illegal content Report content hosted on fortrabbit that is illegal or violates this policy by e-mail to , see [report abuse](/contact/abuse). A report should contain: - the exact URL or other location of the content - an explanation of why the content is illegal or violates this policy - the name and e-mail address of the reporter, except for reports of child sexual abuse material - a statement that the report is made in good faith and that its content is accurate and complete We confirm receipt, decide on the report without undue delay, and inform the reporter of the decision. ## Handling reports We forward a valid report to the responsible customer and set a deadline to remove the content. If the customer does not act, or in urgent cases, we block access to the content or the app. Decisions on reports are made by people. When we restrict content or an account, we tell the customer the reasons, the facts the decision is based on, and how to object: by replying to that e-mail or by legal action. Where content indicates a criminal offence that threatens the life or safety of a person, we inform the police. --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/policies/acceptable-use.md) # AI tool usage and editorial process Source: https://www.fortrabbit.com/legal/policies/ai-usage-policy Published: 2026-01-26 Updated: 2026-09-13 Reviewed: 2026-09-13 > How fortrabbit uses AI in the product and in its own writing, what stays human-reviewed, and how AI involvement is disclosed on each page. ## Required - Use only reputable AI tools - Evaluate security of AI tools before use - Maintain confidentiality and integrity of data and code - Apply standard security practices - Protect confidential data ## Prohibited - Unauthorized data access or handling - Creating or distributing fraudulent or misleading content - Manipulating AI outputs to obscure facts - Sharing data externally without authorization ## AI usage with coding Use artificial intelligence for coding tasks, but stay in control. Suggested usage: - Prototype features - Create tests - Additional PR review - Code non-critical features ## AI usage with content creation Use AI to help draft public-facing articles and posts, but keep it human. All markdown pages on www, docs and blog must carry an AI disclaimer that declares how much AI was used to produce the content. ## Client data We avoid sharing client data with AI tools where it is not needed. To help with a support case or a ticket, an AI tool may read the conversation or ticket content. The AI providers in use are listed on the [sub-processors page](/legal/data-protection/sub-processors). ### Who writes Public-facing prose on fortrabbit.com, docs.fortrabbit.com, and blog.fortrabbit.com is written by the people on our team page plus a small set of declared external contributors. Bylines on blog posts attribute the named author; technical articles and comparison pages attribute the team member who reviewed and signed off on the content, this may surface as the `reviewer` field in frontmatter. ### How review works Every public article may carry two dates in its frontmatter: - `created` — when the page was first published - `reviewed` — the last time a fortrabbit team member read it and confirmed it We treat `reviewed` as the canonical "still accurate as of" stamp. The `reviewer` field records which team member signed off on the most recent review. Older pages display a warning when they have not been reviewed for some time. Some articles — such as old blog posts or legacy install guides — will not receive further review. ### Technical content checks Docs, specs and platform announcements receive a separate technical review on a best-effort basis. Coverage is not guaranteed for every page: high-traffic and platform-critical articles are reviewed more frequently than older or peripheral ones. ### What each `ai` value means Every article footer carries an `ai` disclosure with one of four values, declared in the article's frontmatter: - **`none`** — Written and edited entirely by humans. No AI involvement. - **`grammar`** — Written by a human; AI tools used for grammar, typo, and tone passes only. - **`co-authored`** — Outline, structure, or substantive paragraphs produced collaboratively with an AI tool. Human edited and verified throughout. - **`authored`** — Drafted by an AI tool from a prompt or outline, then reviewed, edited, and verified by a team member before publication. In every case a human reviewed before publishing. ### Flagging inaccuracies If something looks wrong, outdated, or misleading: - Open a PR or issue via the **Edit on GitHub** link in any article footer - Or mail [support@fortrabbit.com](mailto:support@fortrabbit.com) We treat reader-flagged inaccuracies as priority items. ## Compliance All AI use must comply with relevant laws, regulations, data protection laws, intellectual property rights, and industry standards. Violations must be reported and may result in disciplinary action up to and including termination. --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/policies/ai-usage-policy.md) # Copyright Source: https://www.fortrabbit.com/legal/policies/copyright Updated: 2025-02-17 Reviewed: 2025-11-17 12:39:34 > Copyright, trademark use and takedown requests: how to use the fortrabbit name and logo, and how to report infringing content hosted here. ## How we use logos from others All trademarks, logos, and brand names are the property of their respective owners. All company, product, and service names used on this website are for identification purposes only. Use of these names, trademarks, and brands does not imply endorsement or affiliation. You can find logos from software and service providers, such as 'WordPress', 'Laravel' and 'Craft CMS' on our web properties. We are using all these in good good faith, without permission and even without 'contributing back to the community'. If you are copyright owner and don't want us to use your brand, please :ContactUs. ## How you can use the fortrabbit logo Please feel free to use fortrabbit (it's just text set in Georgia italic bold) in similar ways like we use other brands. Please don't claim to be us. ## Copyright infringement and DMCA If you think to have found content hosted here on fortrabbit by one of our customers, that is violating your copyright, please see [abuse contact](/contact/abuse). --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/policies/copyright.md) # Policies Source: https://www.fortrabbit.com/legal/policies Updated: 2026-08-24 > The policies that govern day-to-day platform use: acceptable use, support scope, stress testing, copyright, AI usage and how they change. # Stress testing policies Source: https://www.fortrabbit.com/legal/policies/stress-testing Updated: 2024-01-06 Reviewed: 2025-11-17 12:40:29 > Load and penetration testing on a hosted app is allowed within bounds, because some tests affect other customers. What is permitted, and how. We understand the need to ensure integrity and compliance. Some tests might have adverse impacts on other clients, so we only permit certain types and within certain bounds. Please review this page carefully before getting started. ## Penetration testing and security scans Feel free to perform standard penetration tests and security scans as often as required. Approval from fortrabbit is not required. ## Load testing Please don't run Denial of Service tests and any other type of testing which results in heavy network load. Before running any load test, make sure to have a swift PHP response time for your App already - 200 ms or less. Please respect the following rate limit: * Max 300 RPM Also mind the general platform limits. Each App is different in the way it's built and in the way it is consumed. There are highly dynamic, compute-intensive Apps, and there are Apps that are mostly static. Some have many assets, some none. Some have only one page, some have thousands of pages. You as the developer should know your project, the way it is built and how it will be used. Follow best practices. Get insights from a plugin like Blackfire. --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/policies/stress-testing.md) # Support policy Source: https://www.fortrabbit.com/legal/policies/support-policy Updated: 2024-01-06 Reviewed: 2025-11-17 12:40:58 > What customer support covers, which channels exist, when to expect an answer, and where the line between hosting and application help sits. ## Support scope * Answering general questions about the platform * Providing pointers to documentation * Troubleshooting access * Helping with deployment * Guiding DNS setup * Assisting with configuration * Helping with installing software * Identifying application problems * Providing workarounds or resolutions for known problems * Answering general how-to questions and best practices * Replying to billing related questions * Recommending site architecture ## Not covered * Debugging client application code * Troubleshooting slow MySQL queries * Setting up local development * General performance tuning * Modifying or patching client software * General coding questions * Training in Git ## Code peeking Technically, fortrabbit staff is able to view and even edit all uploaded files and databases. Our aim is to be involved as little as possible. There is an internal policy for that. In many support cases knowledge about configuration or code is essential to find a solution. Where possible and acceptable we will ask for permission to look into your code upfront. In other security related cases, for instance fighting phishing attempts, it is required that we examine code pro-actively. ## Support channel Technical support is available through the web based client support system which can be found on all fortrabbit web properties. ## Support hours Support inquiries may be submitted at any time. ## Response time Every support request will be answered. The main support time frame is bound to our general office hours, Berlin. Monday — Friday, 09:00 — 17:00, excluding public holidays. ## Monitoring The fortrabbit platform is monitored 24/7 by comprehensive automated systems. On-call schedules and escalation policies for technical support are in place. ## Incident handling We will respond swiftly to diagnose and correct platform incidents. In the event of a bigger issue, a notice will be posted on the status site at [status.fortrabbit.com](http://status.fortrabbit.com). --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/policies/support-policy.md) # Update policies Source: https://www.fortrabbit.com/legal/policies/update-policies Updated: 2024-11-13 Reviewed: 2026-04-30 20:45:00 > How and when fortrabbit changes its terms and policies, how customers are notified, and which changes take effect without prior notice. ## Updates performed by customers * It is the responsibility of the customer to update the software they installed - this includes frameworks and Content Management Systems. ## Updates performed by fortrabbit The fortrabbit platform is updated to the latest security patches periodically at irregular intervals. This includes backend services such as networking and containerization not visible to customers, but also client-facing software. ### Communication * Maintenance work with expected downtime will be announced upfront. * Updates containing possibly breaking changes will be communicated as well. This includes major and minor changes, but usually not patch releases. * General instructions on how to update applications are provided on a best-effort basis. * Individual support to update applications is also provided on a voluntary basis. ### New PHP versions * Two or three main PHP versions to choose are usually provided. This can be different major or minor versions. * Access to new versions will be provided some time after the final version will be released. * This is usually after the first important patch release came out and also once all essential extensions are updated. ### Old PHP versions * Outdated PHP versions will be removed once the security support ends (end of life) as defined by the PHP project under [php.net/supported-versions](https://www.php.net/supported-versions.php). * While removing an outdated PHP version, app environments still on that version will be force upgraded to the next old but still supported version of PHP. ### PHP extensions * PHP extensions are usually updated alongside PHP update maintenance. ### Database versions * Database patch updates will be applied automatically. ### TLS certificates * Managed TLS certificates will be automatically installed, approximately every three months. --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/policies/update-policies.md) # Compliance Source: https://www.fortrabbit.com/legal/standards/compliance Updated: 2026-09-13 Reviewed: 2026-09-13 > Common compliance acronyms explained against what fortrabbit actually does: GDPR, DPA, SCC and DSAR, and where each applies to hosting. ## TOM Technical and Organizational Measures: Please also understand that fortrabbit is a software company - a so called Platform as a Service. The actual hosting infrastructure is running on Amazon Web Services (AWS). Standard Technical and Organizational Measures for general hosting services therefore mostly don't apply here. We don't have physical access to data centers and therefore can not grant access to a third party. This aligns with other PaaS vendors on the market, also "only" providing pointers to the infrastructures TOM. ## W-8BEN-E According to our understanding, we are not required to fill out this form. Note that our service headquarter is based in Europe, Berlin. ## COI A Certificate of Insurance document is not common in Europe. However, fortrabbit is a registered GmbH in Germany. The best analogy in English is a Limited Liability Company (LLC). We — like any other hosting company — can not agree to be liable for your losses on downtime, except for cases of gross negligence covered by our [Terms of Service](/legal/contract/terms). We do provide an [Service Level Agreement](/legal/contract/service-level-agreement) which may be relevant to this question. ## NIS2 The NIS2 Directive (EU) 2022/2555 replaced the NIS Directive (EU) 2016/1148 in October 2024. Germany implements it through the BSI Act (BSIG). Cloud computing service providers fall under it from 50 employees, or from more than €10M in both annual turnover and balance sheet total. fortrabbit is below these thresholds, so NIS2 does not apply to us at the moment. ## CPA Nomenclature code That’s a EU standard: CPA 63.11.12 WEB HOSTING SERVICES 63.11.1: Data processing, hosting, application services and other IT infrastructure provisioning services is what we do. ## SO27001 We are not ISO/IEC 27001:2005 certified ourselves, but our infrastructure provider AWS is. ## HIPAA Health Insurance Portability and Accountability Act is a US standard for storing health related data. We can not sign a BAA (Business Associate Agreement). ## W-9 Some clients ask us for a W9 (1099 form), Request for Taxpayer Identification Number and Certification or a W-8-BEN-E. These are US standards to avoid money laundry and some other illegal practices. Sorry no. The fortrabbit company is not in based in the US. As far as we understand, US tax regulations do not apply to us. ## SOC 1 A Service Organization Control 1, or SOC 1 engagement, is an audit of the internal controls at a service organization which have been implemented to protect client data. Sorry, we are NOT doing that. ## SOC 2 If you are hosting or processing other types of information for your clients that does not impact their financial reporting, then you may be asked for a SOC 2 audit report. Sorry, we are NOT doing that. ## SSAE 18 Statements on Standards for Attestation Engagements 16 or 18 (type I ot type II) is a series of enhancements aimed to increase the usefulness and quality of SOC reports, now, superseding SSAE 16. Sorry, we are NOT doing that. ## Custom terms We do not practice custom terms negotiation with individual clients. The fortrabbit hosting platform service scope is a standardized self-service hosting software solution for professionals and small and medium-sized enterprises. We intend to keep our business relations "light-weight". We don't have a legal team on staff. There is no in house expertise to verify in which areas your custom contracts may contradict our standard rules. The fortrabbit platform is constantly evolving. New features will usually affect all clients and already need to be checked against our security standards, privacy rules and legal aspects. --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/standards/compliance.md) # Standards Source: https://www.fortrabbit.com/legal/standards Updated: 2026-08-24 > Security standards and compliance at fortrabbit: the technical and organisational measures, the compliance acronyms and what they mean. # Security measures Source: https://www.fortrabbit.com/legal/standards/security-measures Updated: 2025-11-27 Reviewed: 2025-11-27 12:05:06 > The technical and organisational measures behind the platform, in as much detail as security allows: isolation, access control, patching. While we don't like to expose too much detail — as secrecy is part of security — the following technical and organizational measures may give you some confidence: ## Service scope fortrabbit provides a hosting self-service, granting clients access to technical systems to store and process code via PHP. Clients can store data on a file system and in databases. Think of fortrabbit as a meta-hosting service, or something like a middleware. ## Data centers fortrabbit's physical infrastructure is hosted and managed within Amazon's secure data centers on Amazon Web Services (AWS) technology. These data centers are certified under a number of security standards, including: * ISO 27001 * SOC 1 and SOC 2/SSAE 16/ISAE 3402 * PCI Level 1 * FISMA Moderate * Sarbanes-Oxley (SOX) AWS enforces a high level of physical security to safeguard their data center with military grade perimeter controls and security staff at all points of ingress. As for environmental protection, AWS has sophisticated fire detection and suppression equipment, fully redundant power infrastructure with integrated UPS units and high-end climate control systems to guarantee an optimal working environment for the hardware. For a more in-depth view, we refer you to the [AWS Security Center](https://aws.amazon.com/security). ## SysOps A multi-tier security strategy is employed. On the inside, each Node is built around a hardened Linux kernel, which enforces strong privilege and resource separation mechanisms at OS level. All operating systems and software components are kept up-to-date. At the next tier, each Node exists within isolated virtual containers, which guarantee complete logical separation of Apps. Each App runs within its own isolated environment and cannot interact with other applications or areas of the system. In addition, the container technology allows hard resource capping, which reduces the bad neighbor effect of shared environments to a bare minimum. The setup is designed in a flexible manner to isolate or boost resources quickly. ## Penetration testing Third party security testing is performed by independent security researchers at irregular intervals. Findings from each vulnerability assessment are reviewed with the assessors, risk ranked and resolved swiftly. ## Abuse monitoring User and system activity is monitored for signs of abuse — by algorithms and humans. ## Firewalling On the outside, network firewalling and hardened TCP/IP stacks to mitigate resource exhaustion attempts are utilized. Sniffing and spoofing attacks are prevented through the underlying infrastructure. By default all outgoing traffic on all ports, except for [standard ones](https://www.fortrabbit.com/specs#firewall), is blocked. Clients can request to whitelist a port range. ## Dashboard All communication with the Dashboard is encrypted via TLS. By default users are going to get logged out after some time of inactivity. For "dangerous actions" re-authentication is required. 2FA is available. ## Credit card security A PCI Level 1 compliant provider for processing credit card payments is used. Security policy reviews are executed on a regular basis. ## Internal protocols All employees are trained in safety aspects and best security practices, including how to identify social engineering, phishing scams, and hackers. All employees agree to privacy safeguard policies outlining their responsibility in protecting client data. Binding internal security policies that are evaluated on a regular basis are in place. It is regularly checked whether all responsibilities have been clearly assigned and that they are practicable. There are documented rules and contingency plans. The computer systems of employees are secured by encrypted file systems and password authentication. ## Access control All server accesses are equipped with individual minimum rights and are transmitted in encrypted form. SSH access for clients is "jailed" with outbreak prevention. Access by the contractor's employees will only be via key-pair authentication and where possible through multi-factor authentication. All connections to the server are via encrypted channels and protocols. ## Cryptography All sensible access data is stored "hashed + salted". Asymmetric encryption and AES (Advanced Encryption Standard) encryption are used. ## Supplier relationships All subcontractors are tested for privacy and security suitability. There are appropriate terms in place. ## Not our liability fortrabbit will not perform updates on the CMS or frameworks for clients. You - our client - are liable for the code you write and use on our hosting platform. Update the software you are using frequently. Outdated software puts your project at great risk of being hacked. --- - [GitHub link](https://github.com/fortrabbit/legal/blob/main/standards/security-measures.md) # The new platform Source: https://www.fortrabbit.com/new Published: 2026-03-19 Updated: 2026-03-23 Reviewed: 2026-03-23 > The new fortrabbit platform, in public beta: rebuilt dashboard, per-component pricing, environments per app, and an API built for agents. | | Old platform | New platform BETA | |--------------------|---------------------------------|-----------------------------------------------------------------------------------------------------------| | **Stacks** | Uni + Pro | One unified stack | | **Storage** | Uni: Persistent, Pro: Ephemeral | Persistent storage | | **Structure** | Single app | App + environments · [docs](https://docs.fortrabbit.com/platform/objects/environment) | | **Deployment** | Built-in Git hosting | GitHub integration · [docs](https://docs.fortrabbit.com/platform/deployment/github-app) | | **Build pipeline** | Limited | Advanced with Node.js | | **Collaboration** | Paid feature | Free for all, improved | | **Backups** | Manual | Included, one-click restore · [docs](https://docs.fortrabbit.com/platform/components/backups) | | **Pricing** | Three fixed plans | Component-based | - [See all BETA details](https://docs.fortrabbit.com/platform/new) ## Call for feedback Your input shapes what we will built next. We are crazy to learn what you think. Share your ideas, workflows, and pain points with us — in return, we will credit your account with free hosting time. --- - [What's new and different](/platform/new/changes) - [BETA details](/platform/new/beta) - [Migration guide](/platform/new/migration) # Company plans (old platform) Source: https://www.fortrabbit.com/old-platform/company-plans Published: 2026-03-15 Updated: 2026-07-20 Reviewed: 2026-03-27 > Team work plans on the old fortrabbit platform: what they included, who they were for, and what replaces them on the new platform. This is a legacy feature of the old platform. It's kept here only for reference. ## Company plans | Plan | Target | Support | Members | Billing Contacts | Price | |----------------|------------------|------------|--------:|-----------------:|--------:| | **Company xs** | solo developers | Low prio | 3 | 1 | $0/mo | | **Company s** | busy team | Basic prio | 5 | 5 | $10/mo | | **Company m** | serious business | High prio | 10 | 25 | $50/mo | | **Company l** | large org | Extended | 50 | 100 | $250/mo | ## Workflows that work The flexible Company model suits freelancers working with clients, agencies working with projects and startup teams of all sizes. [Learn more about collaboration ›](https://help.fortrabbit.com/collaboration) ## Delegation Company members can act on behalf of the Company: create new Apps and invite other team members. [Learn more Company collaboration ›](https://help.fortrabbit.com/company-collaboration) ## Role based permissions Different jobs require different access levels. Team members can be Owners and Admins, grant access on App level to Collaborators. [Learn more about roles ›](https://help.fortrabbit.com/company-collaboration#toc-roles) ## Unlimited App Collaboration With any paid Company plan you can invite as many App collaborators to all Apps of the Company as you want. Work together on projects of any size. [About App collaboration ›](https://help.fortrabbit.com/app-collaboration) ## Consolidated billing Create multiple Billing Contacts per Company. Each Billing Contact has it's own payment method and invoice address. [Learn about Billing Contacts ›](https://help.fortrabbit.com/company#toc-billing-contacts) ## Team support The support is aligned with the collaboration features. In other words: All members of your Company have access to support. ## Prioritized support The higher the Company plan, the higher priority in the support queue. We can answer more quickly and take more time to dive into your problems. ## Fast support replies Support is chat. The median first response time is under two hours. Try it out now, by clicking the chat bubble in the bottom right corner. ## Your offshore PHP pros We can assist you with anything from deployment work-flows, to performance tuning, to life-cycle planing, to database support. --- - [Is fortrabbit for you?](/solutions/you) # Old platform Source: https://www.fortrabbit.com/old-platform Published: 2026-05-21 > The old fortrabbit platform: Uni and Pro App specifications, limits, PHP version support, and what carries over to the new platform. # PHP version support Source: https://www.fortrabbit.com/old-platform/php-version-support Published: 2026-01-01 Updated: 2026-05-18 Reviewed: 2026-05-21 This is for the old platform. It's kept here for reference. PHP versions move fast, security support sunsets two years after release, and your code needs a clear runway to keep up. Our [update policies](/legal/policies/update-policies) define the formal commitment; this page is the practical reference. ## PHP compatibility matrix This is the canonical view of which PHP versions you can select for a fortrabbit app today. | PHP version | Available on the old platform | Upstream status | php.net EOL | | ----------- | ------------------------------ | ----------------- | ----------- | | 8.3 | yes (default for new Apps) | Security support | 2027-12-31 | | 8.2 | yes | Security support | 2026-12-31 | | 8.1 | yes | EOL | 2025-12-31 | PHP 8.4 and 8.5 are only available on the [new platform](https://dash.fortrabbit.com/) — see the [PHP 8.5 update](https://blog.fortrabbit.com/php-85-update) for the rationale. Older runtimes (8.0, 7.4) have been phased off the old platform as their upstream security support ended. Patch releases (8.3.18 → 8.3.19 → 8.3.20) are applied automatically on our side. Minor upgrades stay yours to schedule. ## PHP EOL roadmap These are the dates that drive every conversation about when to upgrade. They come from the [official php.net support schedule](https://www.php.net/supported-versions.php). | Version | Released | Active support ends | Security support ends | | ------- | -------- | ------------------- | --------------------- | | 8.5 | Nov 2025 | 2027-12-31 | 2029-12-31 | | 8.4 | Nov 2024 | 2026-12-31 | 2028-12-31 | | 8.3 | Nov 2023 | 2025-12-31 | 2027-12-31 | | 8.2 | Dec 2022 | 2024-12-31 | 2026-12-31 | | 8.1 | Nov 2021 | 2023-11-25 | 2025-12-31 (passed) | | 8.0 | Nov 2020 | 2022-11-26 | 2023-11-26 (passed) | | 7.4 | Nov 2019 | 2021-11-28 | 2022-11-28 (passed) | A version in **active support** still gets bug fixes. A version in **security support** only gets security patches — no new fixes for normal bugs. Once a version passes its security date, the PHP team stops fixing anything, and "best effort" is what every managed host can offer. Most fortrabbit clients should aim to be at most one minor version behind the upstream active release. That is the path of least surprise. ## How fortrabbit handles PHP versions The old platform is a managed PHP host. You pick the runtime; we keep the runtime running. There is nothing to compile, nothing to lock in a Dockerfile, and no proprietary auto-install wrapper sitting between your code and PHP. ### Per-App selection PHP version is set per App. Each App on the old platform runs one runtime at a time. To test a new version safely, create a second App for staging and validate there before flipping the production App. ### Dashboard control The PHP version lives in the PHP settings for each App. Pick a version from the dropdown, save. The new runtime is in place within about two minutes, with no redeploy required — your existing build keeps running. If a new version breaks something you did not anticipate, switching back is the same flow in reverse. There is no "PHP version migration" to roll forward through; the runtime is another setting on the App. ### CLI access For day-to-day work via SSH, the CLI PHP follows the App's PHP version. `ssh you@your-app.eu1.frbit.com php -v` reports whatever you have selected in the dashboard. Composer, `artisan`, `craft`, `wp-cli` — all of these run against the same version as your web requests, which keeps `composer.lock` and runtime behavior in sync. ### From upstream release to availability on fortrabbit Two clocks run in parallel — when PHP itself releases a version, and when that version becomes selectable on fortrabbit. They are not the same date. **Upstream:** the PHP project ships a new minor version roughly every November. Two years later, that version drops into security-only support; another year after that, upstream support ends entirely. The exact dates are in the EOL roadmap above. **On fortrabbit:** per our [update policies](/legal/policies/update-policies), a new PHP version becomes selectable "some time after the final version is released — usually after the first important patch release has come out and once all essential extensions are updated." We typically offer two or three PHP minor versions at any time. The old platform receives PHP updates less often than the new platform; if you need the latest minor sooner than the old platform delivers, the new platform is where it lands first — see the [PHP 8.5 update](https://blog.fortrabbit.com/php-85-update) for a recent example. When a new PHP version lands, we publish a release post on the blog listing exact version pins and any extension changes. ### Patch releases and extensions PHP patch releases on the old platform are applied in the same maintenance windows as the minor updates. PHP extensions — apcu, redis, imagick, mongodb, blackfire — are upgraded as part of those windows, with version pins listed in each release post. See the [update policies](/legal/policies/update-policies) for the formal commitment. If an extension you need is not part of the default set, ask us — the catalog grows when client demand justifies it. ### Composer-first, your code stays your code fortrabbit deploys whatever you push from Git. There are no 1-click installers, no vendor-managed app templates, no autogenerated wrappers that lag behind a framework release. Your `composer.json` is the source of truth for what runs. The practical upshot for PHP versions: when you change the platform's PHP runtime, you are changing what executes against an unchanged codebase. Nothing on our side gets rewritten or downgraded behind your back. ## Plan a PHP version upgrade Three starting points cover most upgrades on the old platform today. ### From PHP 5.6 or 7.0 You are looking at three or four major-version boundaries. The hard breaks are mcrypt (removed in 7.2), `each()` (gone in 8.0), and the strictness of type coercion across the 7 → 8 transition. The safe path: 1. Pin your local development to the same version your App runs today. 2. Bring dependencies up to date. Anything older than 2020 will fight you; expect framework upgrades to be the bulk of the work. 3. Move one minor version at a time locally — 5.6 → 7.0 → 7.1 → 7.2 — and run the test suite at each step. The [PHP 7.2 upgrade path](https://blog.fortrabbit.com/php-upgrade-path) post walks through the original mechanics; they still apply. 4. Once your code runs cleanly on PHP 7.x, flip the dashboard to the target version and verify under production conditions. From there, the 7.x → 8.x guidance below applies. Skipping minors works for some projects, but you lose the ability to bisect when something breaks. For projects this old, the slow walk is usually faster than three days of debugging. ### From PHP 7.x to 8.x This is the upgrade that catches most older Apps. Backward-incompatible changes cluster at the 7.4 → 8.0 boundary and again at 8.1 → 8.2. The well-known traps: - Internal function signatures got stricter — code that silently coerced `null` into a string now throws. - `each()`, `create_function()`, and the `{}` string-offset syntax are gone. - Resource types for several extensions became proper objects. - PHP 8.1 deprecated many implicit nullable parameter declarations. - PHP 8.2 turned dynamic properties into a deprecation warning; PHP 9.0 will make it an error. For an active codebase, run static analysis before you flip the runtime. PHPStan, Psalm, and Rector each ship rule sets keyed to a target PHP version, and they will catch most of the breaks before CI does. If you maintain a framework or CMS — Laravel, Symfony, Craft CMS, WordPress, Statamic — upgrade the framework first, then PHP. Frameworks publish PHP-version support matrices for every release; matching the framework to the runtime is the path most of their changelogs assume. ### From PHP 8.x to the next 8.x Minor-to-minor 8.x upgrades are the easiest case. There are deprecations to clean up but rarely hard breaks. Read the migration guide on php.net — for example, [PHP 8.3](https://www.php.net/manual/en/migration83.php) — and skim "backward incompatible changes". Run your test suite locally against the target version, then flip the runtime in the dashboard and watch logs for `Deprecated` notices for a few days. If the upstream migration guide is short and your test suite is green, the dashboard flip usually takes less time than reading this paragraph. ## Choosing the right PHP version Pick the newest release the platform offers that your codebase still runs cleanly on, and never let an App sit past its upstream security-support EOL date without a plan. Once a version is removed from the old platform, remaining Apps are force-upgraded to the next available one — fixing things in advance is always cheaper than fixing them under pressure. Schedule the next upgrade as soon as the current one lands. The longer the gap between PHP versions, the harder each jump gets — and the more likely you will hit a framework or CMS deprecation that forces a coordinated migration instead of a one-line setting change. If you need PHP 8.4, PHP 8.5, or per-environment runtime selection, that is what the new platform offers. See [dash](https://dash.fortrabbit.com) to start a new App there. For the per-release detail behind any version in the table above, see the changelog posts on the blog: - [PHP 8.5](https://blog.fortrabbit.com/php-85-update) (new platform only) - [PHP 8.4](https://blog.fortrabbit.com/php-84-update) (new platform only) - [PHP 8.3](https://blog.fortrabbit.com/php-83-update) - [PHP 8.2](https://blog.fortrabbit.com/php-82-update) - [PHP 8.1](https://blog.fortrabbit.com/php-81-update) - [PHP 8.0](https://blog.fortrabbit.com/php-8-update) For the older history — PHP 7.4 EOL, PHP 7.1 fade-out, the 5.6 deadline — see [On PHP deadlines](https://blog.fortrabbit.com/on-php-deadlines) and the [PHP EOL FAQ](https://blog.fortrabbit.com/php-eol-faq). If you are not sure which version your App is on or which target makes sense, the dashboard's PHP settings is the source of truth, and our support chat is open for the rest. --- - [Update policies](/legal/policies/update-policies) - [PHP cloud hosting](/php-cloud-hosting) - [Uni Stack specs](/old-platform/specs-uni) - [Pro Stack specs](/old-platform/specs-pro) - [Upgrade PHP - best practices](/dev/how-to/upgrade-php) # Specs Pro Apps Source: https://www.fortrabbit.com/old-platform/specs-pro Published: 2026-03-15 Updated: 2026-07-27 Reviewed: 2026-07-27 > Technical specifications and limits for Pro Apps on the old fortrabbit platform: resources, PHP settings, storage and what is excluded. This is for the old platform. It's kept here for reference. ## Component plans ### PHP scaling | Plan | Level | Views/h | Nodes | PHP | OPcache | Processes | Monthly | | --------- | ----- | -------: | ----: | -----: | ------: | --------: | ------: | | PHP s 1 | Dev | 1k | 1 | 128 MB | 64 MB | 2 | €5 | | PHP s 2 | Prod | 10k | 2 | 128 MB | 64 MB | 4 | €15 | | PHP s 4 | Prod | 20k | 4 | 128 MB | 64 MB | 8 | €30 | | PHP s 8 | Prod | 40k | 8 | 128 MB | 64 MB | 16 | €60 | | PHP m 1 | Dev | 1k | 1 | 256 MB | 128 MB | 2 | €10 | | PHP m 2 | Prod | 10k | 2 | 256 MB | 128 MB | 4 | €30 | | PHP m 4 | Prod | 20k | 4 | 256 MB | 128 MB | 8 | €60 | | PHP m 8 | Prod | 40k | 8 | 256 MB | 128 MB | 16 | €120 | | PHP l 1 | Dev | 1k | 1 | 512 MB | 256 MB | 2 | €15 | | PHP l 2 | Prod | 10k | 2 | 512 MB | 256 MB | 4 | €60 | | PHP l 4 | Prod | 20k | 4 | 512 MB | 256 MB | 8 | €120 | | PHP l 8 | Prod | 40k | 8 | 512 MB | 256 MB | 16 | €240 | | PHP xl 2 | Dedi | 50-125k | 2 | 3 GB | 512 MB | 20-40 | €380 | | PHP xl 4 | Dedi | 100-250k | 4 | 3 GB | 512 MB | 40-80 | €760 | | PHP xl 8 | Dedi | 200-500k | 8 | 3 GB | 512 MB | 80-160 | €1520 | | PHP xl 12 | Dedi | 300-750k | 12 | 3 GB | 512 MB | 120-240 | €2280 | _Larger plans are available on request._ ### MySQL scaling | Plan | Level | Storage | Memory | Connections | IOPS | Monthly | Backup | | --------- | ----- | ------: | -----: | ----------: | -----: | ------: | -----: | | MySQL xxs | Dev | 32 MB | shared | 5 | shared | €2 | n/a | | MySQL xs | Dev | 128 MB | shared | 10 | shared | €5 | n/a | | MySQL s | Prod | 512 MB | shared | 20 | shared | €15 | €5 | | MySQL m | Prod | 2 GB | shared | 35 | shared | €50 | €5 | | MySQL l | Dedi | 50 GB | 2 GB | 70 | 150 | €125 | €10 | | MySQL xl | Dedi | 100 GB | 4 GB | 130 | 300 | €250 | €20 | | MySQL xxl | Dedi | 200 GB | 8 GB | 250 | 600 | €500 | €40 | _Automatic MySQL backups are available for databases on Production and Dedicated levels._ ### Memcache scaling | Plan | Level | Nodes | Memory | Monthly | Daily | | ----------- | ----- | ----: | -----: | ------: | ----: | | Memcache xs | Dev | 1 | 64 MB | €5 | €0.17 | | Memcache s | Prod | 2 | 128 MB | €10 | €0.33 | | Memcache m | Prod | 2 | 256 MB | €20 | €0.67 | | Memcache l | Prod | 2 | 512 MB | €40 | €1.33 | ### Worker scaling | Plan | Nodes | CPU priority | Memory | Jobs | Monthly | Daily | | ----------- | ----: | ------------ | -----: | ---: | ------: | ----: | | Worker s | 1 | very low | 128 MB | 1 | €5 | €0.17 | | Worker m | 1 | low | 512 MB | 4 | €15 | €0.50 | | Worker l | 1 | medium | 1 GB | 8 | €30 | €1 | | Worker xl | 1 | high | 2 GB | 16 | €60 | €2 | | Worker xxl | 1 | high | 4 GB | 32 | €120 | €4 | | Worker xxxl | 1 | dedicated | 7.5 GB | 50 | €250 | €8.33 | ### HTTPS options | Plan | Description | Monthly | Daily | | --------------- | ---------------------------------------- | ------: | ----: | | Automatic HTTPS | Secure TLS connections via Let's Encrypt | €0 | €0 | | Custom HTTPS | Bring your own certificate | €5 | €0.17 | ### Object Storage | Plan | Storage capacity | Monthly | Daily | | ----------------- | ---------------: | ------: | ----: | | Object Storage xs | 100 MB | €1 | €0.03 | | Object Storage s | 2 GB | €5 | €0.17 | | Object Storage m | 20 GB | €15 | €0.50 | | Object Storage l | 100 GB | €45 | €1.50 | | Object Storage xl | 200 GB | €90 | €3 | ## Technical specifications ### Deployment | Setting | Value | | ----------------------------------- | -----: | | PHP memory limit in deployment | 512 MB | | Max time for git push | 20 min | | Max time for git pull | 10 min | | Max time running Composer | 10 min | | Max time running pre script | 10 min | | Max time running post script | 10 min | | Max deployment release package size | 200 MB | ### Remote SSH execution | Setting | Value | | ----------------------------- | -----: | | PHP memory limit in execution | 512 MB | | Max execution time | 20 min | ### Storage & traffic | Setting | Value | | ------------------------------------------ | -------: | | Ephemeral storage per App | 2 GB | | Included traffic per month per App | 50 GB | | Each additional 5 GB traffic | €1 | | Max individual file size in Object Storage | 1500 MB | | Max files per folder in Object Storage | 999 | | Default positive caching (Object Storage) | 24 hours | | Default negative caching (Object Storage) | 1 min | ### MySQL backups | Setting | Value | | ---------------------------- | --------: | | Retention period | 30 days | | EU MySQL backups start | 02:00 UTC | | EU MySQL backups finished by | 10:00 UTC | | US MySQL backups start | 07:00 UTC | | US MySQL backups finished by | 15:00 UTC | ### Software versions | Software | Version | | -------- | ------------: | | Apache | 2.4 | | PHP | 8.3, 8.2, 8.1 | | MySQL | 8.4 | For supported PHP versions, EOL dates, and upgrade paths, see [PHP version support on fortrabbit](/old-platform/php-version-support). ### Firewall allowlisted ports | Service | Port | | ------------------------ | ---: | | SSH | 22 | | SMTP | 25 | | DNS | 53 | | HTTP | 80 | | POP3/APOP | 110 | | HTTPS (SSL) | 443 | | SMTP (Authenticated) | 465 | | SMTP (Authenticated) | 587 | | IMAP SSL | 993 | | POP SSL | 995 | | Apple Push Notifications | 2195 | | Apple Push Notifications | 2196 | | MySQL | 3306 | | PostgreSQL | 5432 | | HTTP (Alternative) | 8080 | | Elasticsearch | 9200 | | Git | 9418 | ### PHP extensions For detailed PHP configuration and available extensions: - [PHP 8.3.x phpinfo()](https://phpinfo-83.frb.io/) - [PHP 8.2.x phpinfo()](https://phpinfo-82.frb.io/) - [PHP 8.1.x phpinfo()](https://phpinfo-81.frb.io/) ## References 1. **Level**: Category and recommended use case (Development, Production, or Dedicated) 2. **Page views per hour**: One page view equals one PHP script execution (recommended, not absolute) 3. **Nodes**: Individual computing instances for data redundancy 4. **Shared**: Runs on shared infrastructure, not on dedicated nodes 5. **CPU priority**: Dedicated CPU resources allocation 6. **PHP memory**: Equals PHP memory_limit setting 7. **OPcache**: Maximum memory for OPcache and APCu 8. **Processes**: Concurrent FastCGI PHP processes 9. **MySQL storage**: Database capacity including indexes 10. **MySQL memory**: Reserved RAM for indices (Dedicated level only) 11. **MySQL connections**: Maximum concurrent connections 12. **MySQL IOPS**: I/O operations per second (Dedicated level only) 13. **Backup price**: Monthly cost for enabling backups 14. **Worker memory**: Total RAM available for background jobs 15. **Worker jobs**: Maximum allowed concurrent jobs 16. **Object Storage**: File storage capacity 17. **Ephemeral storage**: Non-persistent local storage replaced on each deploy 18. **Traffic**: All requests to PHP scripts, static files, and Object Storage 19. **Positive cache**: Cache duration for existing files 20. **Negative cache**: Cache duration for missing files (404) 21. **Backup retention**: Days backups are stored and downloadable 22. **Backup timing**: When snapshots are created and become available ## Additional resources - [Troubleshooting limits](https://help.fortrabbit.com/limits) - [Universal Stack specs](/old-platform/specs-uni) _All specifications apply only to Professional Apps, not Universal Apps. Information is subject to change._ # Specs Uni Apps Source: https://www.fortrabbit.com/old-platform/specs-uni Published: 2026-03-15 Updated: 2026-07-27 Reviewed: 2026-07-27 > Technical specifications and limits for Uni Apps on the old fortrabbit platform: resources, PHP settings, storage and what is excluded. This is for the old platform. It's kept here for reference. ## App plans | Specification | Light (trial) | Standard | Plus | | --------------- | ------------: | -------: | -----: | | PHP processes | 2 | 4 | 8 | | PHP memory | 128 MB | 256 MB | 512 MB | | Page views/hour | 1k | 2k | 4k | | Web storage | 1 GB | 5 GB | 10 GB | | MySQL storage | 256 MB | 512 MB | 1 GB | | Backups | No | Yes | Yes | | Cron jobs | No | Yes | Yes | | Monthly price | €5 | €15 | €30 | | Daily price | €0.17 | €0.50 | €1 | _Prices are per App. Multiple Apps can be created per account._ ## Technical specifications ### Deployment | Setting | Value | | ----------------------------------- | -----: | | PHP memory limit in deployment | 512 MB | | Max time for git push | 20 min | | Max time for git pull | 10 min | | Max time running Composer | 10 min | | Max time running pre script | 10 min | | Max time running post script | 10 min | | Max deployment release package size | 200 MB | ### Traffic & temporary storage | Setting | Value | | ---------------------------------- | ----: | | Included traffic per month per App | 50 GB | | Each additional 5 GB traffic | €1 | | Temporary storage per App | 2 GB | ### Backups | Setting | Value | | ---------------------------- | --------: | | Retention period | 14 days | | EU MySQL backups start | 02:00 UTC | | EU MySQL backups finished by | 10:00 UTC | | EU code backups start | 03:30 UTC | | EU code backups finished by | 17:30 UTC | | US MySQL backups start | 07:00 UTC | | US MySQL backups finished by | 15:00 UTC | | US code backups start | 07:00 UTC | | US code backups finished by | 23:00 UTC | ### Software versions | Software | Version | | -------- | ------------: | | Apache | 2.4 | | PHP | 8.3, 8.2, 8.1 | | MySQL | 8.4 | For supported PHP versions, EOL dates, and upgrade paths, see [PHP version support on fortrabbit](/old-platform/php-version-support). ### SSH & SFTP | Setting | Value | | --------------------- | -----------------: | | Available memory | Same as PHP memory | | Max concurrent logins | 5 | ### Cron jobs | Setting | Value | | ---------------- | ------------------------------ | | Interval options | hourly, daily, weekly, monthly | Cron jobs are available on the Standard and Plus plans, not on Light. ### Firewall allowlisted ports | Service | Port | | ------------------------ | ---: | | SSH | 22 | | SMTP | 25 | | DNS | 53 | | HTTP | 80 | | POP3/APOP | 110 | | HTTPS (SSL) | 443 | | SMTP (Authenticated) | 465 | | SMTP (Authenticated) | 587 | | IMAP SSL | 993 | | POP SSL | 995 | | Apple Push Notifications | 2195 | | Apple Push Notifications | 2196 | | MySQL | 3306 | | PostgreSQL | 5432 | | HTTP (Alternative) | 8080 | | Elasticsearch | 9200 | | Git | 9418 | ### PHP extensions For detailed PHP configuration and available extensions: - [PHP 8.3.x phpinfo()](https://phpinfo-83.frb.io/) - [PHP 8.2.x phpinfo()](https://phpinfo-82.frb.io/) - [PHP 8.1.x phpinfo()](https://phpinfo-81.frb.io/) ## References 1. **PHP processes**: Defines concurrent connections capacity 2. **Page views per hour**: One page view equals one PHP script execution (recommended value, not absolute limit) 3. **PHP memory**: Equals PHP memory_limit setting 4. **MySQL storage**: Database capacity including indexes 5. **Cron jobs**: Whether scheduled tasks can be configured 6. **SSH memory**: RAM available for PHP application execution 7. **Concurrent logins**: Parallel SSH and/or SFTP connections allowed 8. **Web storage**: Total file storage capacity on disk 9. **Temporary storage**: Available space for temporary files (`/tmp`) 10. **Deployment package**: Compressed archive size limit for deployed files 11. **Deployment memory**: Memory for Composer, scripts, and SSH execution 12. **Traffic**: All requests to PHP scripts, static files, and Object Storage 13. **Backup retention**: Days backups are stored and accessible 14. **Backup timing**: When snapshots are created and become available ## Additional resources - [Troubleshooting limits](https://help.fortrabbit.com/limits) - [Professional Stack specs](/old-platform/specs-pro) _All specifications are subject to change. For the most current information, please refer to the dashboard or contact support._ --- - [PHP version support](/old-platform/php-version-support) # PHP cloud hosting for the rest of us Source: https://www.fortrabbit.com/php-cloud-hosting Published: 2026-03-15 Updated: 2026-10-18 Reviewed: 2026-10-13 > PHP hosting on AWS with git push deploys, managed MySQL, SSL and backups. No operating system to patch. Components from €2.50 a month. fortrabbit is managed PHP cloud hosting: a platform that runs PHP and nothing else, on AWS, since 2012. We operate the operating system, the PHP runtime from 8.1 to 8.5, the MySQL component, the TLS certificates and the daily backups; the developer pushes code. A push to the connected GitHub branch starts a build on fortrabbit, Composer and npm run there, and the release goes live only when the build succeeds. Every environment comes with SSH and SFTP access in a jailed shell, its own HTTPS test domain and its own components, and an app holds as many environments as a project needs, so staging and production run the same code at different sizes. Pricing is per component and per day, from €2.50 a month for the smallest environment, with no bundles and no minimum term. Regions are Ireland and Virginia. Left out on purpose: a control panel, 1-click installers, root access, and automatic updates to the software you deployed. PHP cloud hosting otherwise means whatever the seller needs it to mean. Shared hosters put the words on the same oversold box they always sold. The hyperscalers mean a menu of 200 services you assemble yourself. We mean the paragraph above. [Start a free trial — no credit card](/signup) ## Who maintains what on shared, VPS and cloud hosting | | Shared hosting | VPS | Hyperscaler | fortrabbit | | ------------ | -------------- | -------- | --------------- | ------------- | | Hardware | provider | provider | provider | us, on AWS | | OS patches | provider | you | you | us | | PHP versions | provider | you | you | us | | Database | shared | you | you, or managed | us, isolated | | TLS certs | provider | you | you | us | | Backups | varies by plan | you | you | us, daily | | Deploy | FTP or a panel | you | you | git push | | App code | you | you | you | you | Shared hosting and fortrabbit both take the server off your hands. On fortrabbit a build runs Composer on every push, and the database is not shared with the neighbors. ## For the rest of us The big clouds assume a platform engineer on the team. Shared hosting assumes nobody will ever open a terminal. In between is everyone else: the freelancer with 11 client sites, the two-person agency, the developer who wants a staging environment without also wanting Kubernetes. If you are good with Git and Composer and would rather not own an operating system, this fits. If you want a control panel with a one-click WordPress button, it does not, and we would rather say so now than take the money. ## What a month costs The smallest app is €2.50. Nothing is bundled — PHP, MySQL, storage, traffic, backups, and jobs are booked separately and [scaled separately](/how-to-scale-a-php-application), so a database that outgrows its size does not drag the PHP component up with it. Billing runs in arrears, by the day. Book a component for three days, pay for three days. Delete an environment and it stops costing money that afternoon. No annual plan to escape from. Every new app starts on a [seven-day free trial](/php-hosting/with-free-trial) with every component and no credit card. The [pricing page](/pricing) has the full matrix. ## git push is the deploy Composer runs inside the build. Either the build succeeds and the release goes live, or it fails and the old version keeps serving — there is no half-deployed state to clean up afterwards. Deploy on merge through the [GitHub integration](/features/github-integration). [SSH and SFTP](/php-hosting/with-ssh-access) are open for CLI commands and cron jobs. Not for installing things: the shell is jailed, there is no root, and a Node toolchain or FFmpeg will not run there. That trade is the point. Somebody has to patch the operating system, and if that somebody were you, this would be a VPS. The [PHP hosting pages](/php-hosting) answer the common constraints one by one: SSH, backups, staging, git push, updates, no cPanel, and [affordable with MySQL](/php-hosting/affordable). An app holds as many [environments](https://docs.fortrabbit.com/platform/objects/environment) as it needs, each one isolated and scaled on its own. Production and staging, same code, different sizes. The [architecture page](/platform/architecture) shows how the pieces sit together. ## Things we don't do Listed here because these are the usual reasons to walk away, and finding out after the migration is worse. - **No 1-click installers.** A fresh Laravel or Craft CMS install is an empty shell anyway. Composer-first keeps the repository as the source of truth. - **No automatic updates** to the software you brought. That call is yours. - **No [free migrations](/platform/no-x).** A migration somebody else performed leaves nobody who understands it. - **No phone number and no enterprise tier.** Support is chat, the same chat for everyone. ## What people run here Craft CMS, WordPress, Statamic, Kirby, TYPO3, Drupal. Laravel, Symfony, Tempest, CodeIgniter, Yii. Anything on PHP 8 with a LAMP-shaped stack will run — the [software pages](/software) carry the per-stack notes. Pick a region when the app is created: Ireland for the EU, or the US. ## Coming from somewhere else The [migration guide](https://docs.fortrabbit.com/dev/how-to/migrate-to-fortrabbit) covers the general path, and the [comparison pages](/alternatives) have cutover notes for the provider you are leaving. Do it on the trial: run a copy here, look at it, and only then touch DNS. ## FAQ ### Is fortrabbit managed hosting? **Yes** — In the automated sense — the platform is managed: PHP versions, MySQL, SSL, backups. Standardized, not bespoke. For white-glove custom setups, look for a provider that says plainly who manages the operating system. ### Which PHP versions are supported? **Several** — fortrabbit runs a range of current and older PHP versions. The PHP version is picked per app, so an app can stay on an older release or move to a current one when ready. ### How is a PHP app deployed? **Git push** — Deployment runs over git push. Composer installs dependencies during an atomic build, and the new release goes live only once the build succeeds. SSH access is available for CLI commands and cron jobs. ### Is there SSH access? **Yes** — Full SSH access is included for running CLI commands and cron jobs. There is no root access — fortrabbit is a Platform as a Service, not a VPS. ### Which databases are available? **MySQL** — A MySQL component is available and can be booked per environment. It is managed as part of the platform, with secure access over the SSH tunnel. --- - [What it costs](/pricing) - [PHP versions](/platform/components/php) - [All features](/features) # Affordable PHP hosting with MySQL Source: https://www.fortrabbit.com/php-hosting/affordable Published: 2026-10-01 Updated: 2026-10-18 Reviewed: 2026-10-01 > Affordable PHP hosting with MySQL on fortrabbit: PHP, MySQL, storage, traffic and backups priced per component and billed per day. No tiers, no bundles. fortrabbit is affordable managed PHP hosting with MySQL, priced per component and per day, with no bundled tiers. The smallest environment, PHP XS with storage, traffic and one daily backup, costs €2.50 a month, and MySQL is booked on top of that. A Craft CMS or Laravel app with a 512 MiB PHP plan, 1 GiB MySQL, 2 GiB storage and three backups comes to €19. Every component scales on its own, so a growing database does not force a larger PHP plan. Storage, traffic and MySQL autoscale into the next plan when they fill up; PHP is sized by hand. Billing runs in arrears by the day: book a component for three days, pay for three days, and a deleted environment stops costing money the same day. Prices are the same number in EUR and USD. Every new app starts with seven free days, no credit card, and there is no minimum term. ## PHP and MySQL prices per component The [pricing page](/pricing) lists every step in between. | Component | Smallest | Largest | Autoscales | | -- | -- | -- | -- | | PHP | XS, 128 MiB, 2 processes: €1 | 2XL, 4 GiB, 12 processes: €50 | No | | MySQL | XS, 128 MiB: €1 | 3XL, 40 GiB, 7 GiB memory: €240 | Yes | | Storage | XS, 512 MiB: €0.50 | 3XL, 32 GiB: €32 | Yes | | Traffic | XS, 32 GiB: €0.50 | 2XL, 1 TiB: €64 | Yes | | Backups | XS, 1 copy: €0.50 | 2XL, 48 copies: €64 | No | | Jobs | XS, 1 job: €1 | 2XL, 32 jobs: €60 | No | MySQL and jobs are optional, the rest is part of every environment. The [components concept](https://docs.fortrabbit.com/platform/concepts/components) explains how plans and sizes fit together. ## Three affordable stacks, priced | | Side project | Small site | Agency client | | -- | --: | --: | --: | | PHP | XS €1 | SM €2 | MD €4 | | MySQL | – | XS €1 | LG €8 | | Storage | XS €0.50 | SM €1 | MD €2 | | Traffic | XS €0.50 | XS €0.50 | SM €1 | | Backups | XS €0.50 | XS €0.50 | SM €4 | | Per month | €2.50 | €5 | €19 | [Staging environments](/php-hosting/with-staging-environments) book their own components and usually sit in the first column. ## Not on the bill TLS certificates, the test domain, SSH, GitHub deploys with builds, team members and support chat. The [cost breakdown](/us/cost-breakdown) shows where the money goes. ## FAQ ### Is there a free plan? **A trial** — Every new app runs seven days for free, with any component in any size and no credit card. After that, billing is per component, in arrears, by the day. ### What happens when a site outgrows its plan? **One component grows** — Storage, traffic and MySQL autoscale into the next plan when they fill up. PHP is sized by hand in the dashboard and takes effect within minutes. No other component changes. ### Are prices different in USD? **Same number** — Every plan costs the same figure in EUR and USD. The currency follows the payment method. --- - [Pricing](/pricing) - [Components](/platform/concepts/components) - [Cost breakdown](/us/cost-breakdown) # PHP hosting questions, answered Source: https://www.fortrabbit.com/php-hosting Published: 2026-10-01 Updated: 2026-10-17 Reviewed: 2026-10-01 # PHP hosting with automatic updates Source: https://www.fortrabbit.com/php-hosting/with-automatic-updates Published: 2026-10-01 Reviewed: 2026-10-01 > Which updates fortrabbit applies on its own: operating system, PHP runtime, MySQL, TLS. Which it never touches: the application and its dependencies. PHP 8.1 to 8.5, per environment. fortrabbit is managed PHP hosting where the platform updates itself and the application does not. The operating system, the PHP runtime, the MySQL component, the TLS certificates and the backup service are maintained and patched by fortrabbit following upstream security advisories, with no maintenance window to book and no server to log into. PHP 8.1 through 8.5 are available, with 8.5 as the default for new environments; the major version is chosen per environment in the dashboard and switches in minutes, and patch releases within that version are applied by fortrabbit. What fortrabbit never updates is the software in the repository: Laravel, Craft CMS, WordPress, plugins and Composer dependencies stay at the version the developer deployed. That is deliberate. An unattended CMS update can break a site at night with nobody watching, and the developer who owns the code is the one who can test the upgrade on a [staging environment](/php-hosting/with-staging-environments) first. ## Updates applied by fortrabbit - Operating system and container images - PHP runtime and its extensions, within the chosen major version - MySQL component - Apache, TLS certificates, the deploy service - Backup service and object storage ## Updates applied by the developer - Framework and CMS core: Laravel, Symfony, Craft CMS, WordPress, Statamic … - Plugins, modules, themes - Composer and npm dependencies - The PHP major version, when the code is ready for it The split is written down on the [security page](/platform/security): we run the stack below the app, the developer owns the code on top. The reasoning for leaving application updates alone is on the [no X page](/platform/no-x). ## PHP versions and end of life | Version | Upstream end of life | | -- | -- | | 8.1 | 2025 | | 8.2 | 2026 | | 8.3 | 2027 | | 8.4 | 2028 | | 8.5 | 2029, default | An environment can stay on an older release while a dependency catches up, and move when the code is ready. The [PHP component docs](https://docs.fortrabbit.com/platform/components/php) cover memory, processes and settings per plan. ## FAQ ### Does fortrabbit update WordPress, Craft or Laravel? **No** — The code in the repository, including plugins and Composer dependencies, stays at the deployed version. Upgrades are tested on a staging environment and deployed with git push, by the developer. ### Which PHP versions are available? **8.1 to 8.5** — PHP 8.1, 8.2, 8.3, 8.4 and 8.5, with 8.5 as the default for new environments. The version is set per environment in the dashboard and switches within minutes. ### Is there a maintenance window? **No** — Platform updates roll out without a booking or a notice to act on. There is no server to log into and nothing to approve. --- - [Security](/platform/security) - [No automatic updates](/platform/no-x) - [PHP component](/platform/components/php) # PHP hosting with backups included Source: https://www.fortrabbit.com/php-hosting/with-backups-included Published: 2026-10-01 Reviewed: 2026-10-01 > Every fortrabbit environment books a backup plan, from one daily copy at €0.50 a month. Full file and MySQL backups, encrypted, offsite, restored from the dashboard. fortrabbit is managed PHP hosting with backups included: the backup component is booked with every environment. The smallest plan keeps one daily copy for €0.50 a month, the largest keeps 48 copies for €64. Each backup is full, a complete archive of the environment's files plus a mysqldump of the database when a MySQL component is booked. Backups run once every 24 hours at a randomized time, and a manual backup can be started from the dashboard before a risky deploy. Copies are encrypted and stored on object storage in the app's region, Ireland or Virginia, separate from the web storage, and they do not count towards the storage plan. Restore is self-service from the dashboard, and every backup can be downloaded as files. Production and staging environments are backed up separately, each with its own plan. There is no point-in-time recovery and no committed recovery time; the dashboard lists every stored backup with date and size, plus the time of the next one. ## What a backup contains | Question | Answer | | -- | -- | | Scope | Environment files and a `mysqldump` of its database | | Type | Full, no incremental or differential | | Frequency | Every 24 hours, plus manual backups | | Location | Encrypted object storage in the app's region | | Restore | Dashboard, or download the files | | Monitoring | fortrabbit is alerted on failed jobs | Cache and log paths are left out of the archive. Auditors asking under ISO 27001 or ISO 22301 get the same table in the [backup docs](https://docs.fortrabbit.com/platform/components/backups), with the excludes spelled out. There are no success mails; the dashboard is the record. ## Backup plans and prices | Plan | Copies kept | Per month | | :--- | ---: | ---: | | XS | 1 | €0.50 | | SM | 3 | €4 | | MD | 6 | €8 | | LG | 12 | €16 | | XL | 24 | €32 | | 2XL | 48 | €64 | The plan is changed per environment at any time. Like every component, it is billed by the day and in arrears. Prices are the same number in USD. The [backups feature page](/features/backups) lists the use cases, from a deleted template to a hacked site. ## Where a backup is not the answer A backup restores an environment to yesterday. It does not replace version control for code, which lives in the Git repository, and it does not catch a bug that has been writing wrong data for a week. Test on a [staging environment](/php-hosting/with-staging-environments) first. ## FAQ ### Are backups optional? **No** — Every environment books a backup plan. The smallest keeps one daily copy for €0.50 a month, which is why the smallest environment costs €2.50 rather than €2. ### How is a backup restored? **From the dashboard** — Pick the backup in the environment's backups section and restore it. Files and database come back as they were at that time. A restore takes minutes to hours depending on size; there is no committed recovery time. ### Is there point-in-time recovery? **No** — Each backup is a full snapshot: a complete file archive plus a complete mysqldump. There are no incremental backups and no binlog replay. A manual backup before a risky change covers most of that gap. --- - [Backups](/features/backups) - [Restore from backup](/platform/backups/restore) - [Component prices](/pricing) # PHP hosting with a free trial Source: https://www.fortrabbit.com/php-hosting/with-free-trial Published: 2026-10-17 Reviewed: 2026-10-17 > Every new fortrabbit app starts a seven-day free trial with no credit card: all components, git push deploys, SSH and staging environments. fortrabbit is managed PHP hosting with a free trial on every new app: seven days, no credit card, on the same platform paying customers run on. A trial app books PHP, MySQL, storage, traffic, backups and jobs in any size up to a monthly cost threshold; a larger setup needs a payment method attached, which is still not charged during the trial. The trial includes git push deploys from GitHub with Composer builds, SSH and SFTP access, staging environments, an HTTPS test domain and team invites. A countdown in the dashboard shows the time left, and an e-mail goes out before the end. Without a payment method, the app, its environments and their data are deleted when the seven days are over. With one, the app keeps running and billing starts by the day for the booked components. Each new app starts its own trial, so a client demo or a weekend project gets seven days of its own. ## What happens when the free trial ends | Payment method on the app | At trial end | | -- | -- | | None, the default | App, environments and data are deleted | | Attached during the trial | App keeps running, billing starts by the day | Billing runs in arrears per component, from €2.50 a month for the smallest environment. The [pricing page](/pricing) lists every plan. ## Limits of the free trial - Seven days, extended by support on request before the end. - A setup above the monthly cost threshold needs a payment method before it can be booked. - Several trial apps at once without a payment method get shorter trials. - Deletion at trial end is final, so keep the code in Git and a local copy of the database. ## Testing a migration on the trial Run a copy of the current site on a trial app, check it on the test domain, and only then touch DNS. The [migration guide](https://docs.fortrabbit.com/dev/how-to/migrate-to-fortrabbit) covers the steps, and the [alternatives pages](/alternatives) carry notes per provider. ## FAQ ### Is a credit card needed for the free trial? **No** — A trial app runs without any payment method. A payment method is only needed to keep the app after seven days, or to book a setup above the trial's cost threshold. Nothing is charged during the trial either way. ### What happens to the data when the trial ends? **Deleted, unless kept** — Without a payment method, the app, all its environments and their data are deleted at the end of the trial. An e-mail goes out ahead of time, and the dashboard shows a countdown. Attach a payment method before the end to keep everything as it is. ### Can the trial be extended? **Ask support** — Yes, on request before the trial ends. Write to support what is being tested and why more time helps. Most requests are granted. --- - [Test for free](/benefits/try-free) - [Free trial details](/platform/get-started/free-trial) - [Pricing](/pricing) # PHP hosting with git push deploy Source: https://www.fortrabbit.com/php-hosting/with-git-push-deploy Published: 2026-10-01 Reviewed: 2026-10-01 > Deploy PHP to fortrabbit by pushing to GitHub. Composer and npm run in a separate build service, the release is atomic, uploads survive. GitLab, Bitbucket and Codeberg deploy over CI. fortrabbit is managed PHP hosting with git push deploy as the default. The fortrabbit GitHub App connects a repository to an app and a branch to each environment; a push to the branch starts a deployment on fortrabbit, with no GitHub Actions minutes involved. The build runs in a separate deploy service with the same PHP version as the environment: `composer install`, then an npm build when the project has one, both pre-configured by the software template for Laravel, Craft CMS, Statamic, Kirby, WordPress and others. If a build step fails, the deployment stops and the previous release keeps serving. Post-deploy commands such as migrations and cache clears run on the web runtime afterwards. Storage is persistent: a deploy overwrites code and leaves uploads, sessions and the database untouched, or replaces the whole web space when the project is built for immutable releases. Repositories on GitLab, Bitbucket or Codeberg deploy through their own CI pipelines over SSH deploy keys. Every new app starts with a seven-day trial. ## The git push deploy pipeline ```raw 1 Local 2 Git provider 3 fortrabbit 4 environment ┌─────┐ ┌────────────┐ ┌──────────────┐ ┌──────────────┐ │ Git ├───▶ Git repo ├───▶ Deployment ├───▶ web space │ └─────┘ └────────────┘ └──────────────┘ └──────────────┘ ``` The deploy service is its own container, so a heavy `npm run build` does not take memory from visitors. Dependencies are cached between deploys. Source directory, exclude patterns and [build commands](/features/build-commands) are set in the dashboard or in a [deploy file](https://docs.fortrabbit.com/platform/deployment/deploy-file) in the repository. ## Two deployment strategies - Merge: newer files replace older ones, new files are added, nothing else is touched. The default, and the right one for a CMS whose editors upload files. - Replace: the web space is wiped and rebuilt from the deploy package, except for the paths in the exclude patterns. Immutable releases for twelve-factor style apps. ## Git syncs up only Code goes up through Git. Content comes down through SSH and SFTP. A file uploaded over SFTP never shows up in the repository, which keeps the repository free of binaries and runtime data. The [deployment intro](https://docs.fortrabbit.com/platform/deployment) draws the full picture, including what the storage holds after a deploy. The [GitHub integration page](/features/github-integration) covers installing the app and connecting a repository. ## FAQ ### Are GitHub Actions required? **No** — The fortrabbit GitHub App connects to the repository directly. The build runs on fortrabbit, so no Actions minutes are spent. Actions can still be used as an alternative trigger, with a deploy key. ### What happens when composer install fails? **Nothing goes live** — The deployment is aborted and the previous release keeps serving. The deploy log in the dashboard shows the failing step. ### Do deploys delete uploads? **No** — The default merge strategy overwrites files from the build and leaves everything else alone, so uploads, transforms and sessions persist. The replace strategy wipes the web space first and keeps only the paths named in the exclude patterns. --- - [GitHub integration](/features/github-integration) - [Build commands](/features/build-commands) - [Git hosting](/integrations/git-providers) # PHP hosting with SSH access Source: https://www.fortrabbit.com/php-hosting/with-ssh-access Published: 2026-10-01 Reviewed: 2026-10-01 > SSH and SFTP on every fortrabbit environment, included in each PHP plan from €1 a month. Run artisan, Composer and rsync; no root, no package installs. fortrabbit is managed PHP hosting with SSH access on every plan. Each environment has its own SSH and SFTP login, authenticated by public key; the smallest PHP plan costs €1 a month and SSH is part of it. The shell runs in the same container as the website, so `php artisan`, `php craft`, `composer install`, `wp` and `mysqldump` work against the live files and the booked MySQL component. rsync moves uploads up and down, and the same SSH connection tunnels a local database client to MySQL. The shell is jailed: no root, no sudo, no package manager. Software beyond PHP, such as Node, FFmpeg or image optimizers, cannot be installed; the operating system and the PHP runtime are patched by fortrabbit. Regions are Ireland and Virginia, and the SSH host name carries the region. Code is deployed with git push; SSH covers the work between deploys, such as a one-off import or a look at the logs. ## What runs over SSH - Framework and CMS consoles: `php artisan`, `php craft`, `php bin/console`, `wp`. The `php` prefix is required. - Composer, when a build needs a manual `composer install`. Deploys run it on their own. - `mysqldump` and `mysql` against the environment's database, and an SSH tunnel for a desktop client. - rsync and SFTP for uploads, transforms and other runtime data that does not belong in Git. The [SSH and SFTP feature page](/features/ssh-sftp) has the sync patterns. - Reading logs and deployed files in place. ## What the SSH shell does not do - Install or remove system packages. No Node toolchain, no FFmpeg, no `apt`. - Run long-lived processes. Workers and cron jobs run in the [jobs component](https://docs.fortrabbit.com/platform/components/jobs), managed from the dashboard, with their own memory. - Heavy lifting. The shell shares memory and CPU with the web runtime, so a large import competes with visitors. ## Personal SSH keys SSH keys are uploaded to a personal account, not to a shared hosting login. Each developer connects with their own key, so onboarding and offboarding means adding or removing a key rather than rotating a password everyone knew. Deploy keys cover services such as GitHub Actions. The [SSH key setup guide](https://docs.fortrabbit.com/dev/learn/ssh-key-setup) walks through generating and uploading a key. ## FAQ ### Is there root access? **No** — The shell is jailed. Commands run as the environment's own user, with no sudo and no package manager. fortrabbit patches the operating system and the PHP runtime; the developer owns the code on top. ### Can a database client connect over SSH? **Yes** — The MySQL component is not exposed to the internet. Sequel Ace, TablePlus, MySQL Workbench and the mysql CLI connect through an SSH tunnel to the environment, with the credentials from the dashboard. ### Do SSH logins cost extra? **No** — SSH and SFTP come with every PHP plan, from the €1 XS plan up. Access is per account, by public key. Every team member brings their own key, and a deploy key can be issued for a CI service. --- - [SSH and SFTP](/features/ssh-sftp) - [SSH key authentication](/features/ssh-key-authentication) - [Code access](/platform/code-access) # PHP hosting with staging environments Source: https://www.fortrabbit.com/php-hosting/with-staging-environments Published: 2026-10-01 Updated: 2026-10-18 Reviewed: 2026-10-01 > Production and staging as separate environments of one fortrabbit app. Each maps to a Git branch, books its own components and has its own HTTPS test domain, from €2.50 a month. fortrabbit is managed PHP hosting with staging environments built into the model: an app holds any number of environments, and each one is a complete, isolated hosting setup with its own PHP runtime, storage, MySQL, environment variables, SSH login and HTTPS test domain. Connected to GitHub, each environment maps to a branch, so a push to `staging` deploys staging and a push to `main` deploys production. Components are booked per environment and billed by the day, which lets staging run on the smallest sizes at €2.50 a month while production is sized for its traffic. Environments are stateful: uploads, sessions and the database belong to the environment and survive deployments, so production data reaches staging only when somebody syncs it down, with mysqldump and rsync over SSH. The API and the MCP server create a new environment as a copy of an existing one, components and settings included. Every new app starts with a seven-day trial without a credit card. ## One app, a production and a staging environment ```raw app: client-site ├── main ← production PHP MD · MySQL LG · 6 backups ├── staging ← staging PHP XS · MySQL XS · 1 backup └── redesign ← temporary PHP XS · MySQL XS · 1 backup ``` Each line is a branch and an environment. Services run separated, so a load test on staging does not slow production, and a broken deploy on `redesign` leaves `main` serving. The [staging environments feature page](/features/staging-environments) describes the isolation in more detail. ## What stays separate per environment - Components and their sizes, billed per environment - Environment variables, PHP version and PHP settings - Files, uploads, sessions and the database - Domains, certificates and the [test domain](/features/test-domain) - Deployment settings: branch, build commands, strategy ## Runtime data is the hard part A content editor publishes on production while a developer tests on staging with last month's database. That gap exists on every platform with stateful environments. The [staging guide](https://docs.fortrabbit.com/dev/learn/staging-environments) covers the usual set-ups and how to sync a database down. Most frameworks read the stage from an environment variable, which each environment sets on its own. ## FAQ ### What does a staging environment cost? **From €2.50 a month** — Staging books its own components and can run on the smallest sizes: PHP XS, 512 MiB storage, 32 GiB traffic and one daily backup come to €2.50 a month. Billing is by the day, so a temporary environment for a two-week redesign costs two weeks. ### How does a change move from staging to production? **Merge and push** — Each environment follows a Git branch. Merge staging into main and push; the GitHub App deploys production with the same build steps. Database contents and uploads are not promoted with the code. ### Does staging get its own HTTPS domain? **Yes** — Every environment comes with a frbit.app test domain and a TLS certificate, ready to share with a client before any DNS is touched. Custom domains can be added per environment as well. --- - [Staging environments](/features/staging-environments) - [Test domain](/features/test-domain) - [The environment](/platform/objects/environment) # PHP hosting without cPanel Source: https://www.fortrabbit.com/php-hosting/without-cpanel Published: 2026-10-01 Reviewed: 2026-10-01 > fortrabbit replaces the control panel with a dashboard, git push deploys, SSH and an API. No cPanel, no 1-click installers, no email hosting, no domain registration. fortrabbit is managed PHP hosting without cPanel, Plesk or any classical control panel. In their place is a self-service dashboard for apps, environments, components, domains and PHP settings, plus a public API, a CLI and an MCP server that expose the same operations to scripts and coding agents. Code reaches the server by git push through the GitHub App or over SSH and SFTP, not through a file manager. There are no 1-click installers: Laravel, Craft CMS, WordPress or Symfony are installed by Composer from the repository, so the deployed code matches version control. Things a cPanel account bundles are absent on purpose: no email hosting, no domain registration, no phpMyAdmin on the server, no root shell. Mail goes through a transactional provider, domains stay at the registrar and point to the environment, and a local database client connects over the SSH tunnel. The smallest environment costs €2.50 a month, and every new app starts with seven free days. ## What replaces cPanel - Apps and environments, with components sized per environment - PHP version, extensions and settings per environment - Domains and automatic TLS certificates - Deployment settings, deploy logs, build commands - Environment variables, SSH keys, team members - Backups, restores, metrics and logs Everything in that list is also an API call. The [automation docs](https://docs.fortrabbit.com/platform/automation) cover the [public API](/features/public-api), the `frbit` CLI and the [MCP server](/features/mcp-server). ## Missing on purpose | cPanel | fortrabbit | | -- | -- | | File manager | git push, SFTP, rsync | | Softaculous installers | Composer, from the repository | | Email accounts | Transactional mail provider | | Domain registration | Any registrar, pointed at the environment | | phpMyAdmin | SSH tunnel for a desktop client | | Root or reseller access | Jailed shell per environment, keys per person | The reasoning for each gap is on the [no X page](/platform/no-x). A platform that runs only PHP can leave out the parts of a panel that need a mail server, a DNS server or root on the box. ## Who PHP hosting without a panel fits Developers who deploy from a repository and would rather not own an operating system. A freelancer with a dozen client sites gets one dashboard, individual logins per collaborator and a handover that is a team change rather than a password reset. Somebody who wants a WordPress button and an email inbox on the same invoice is better served by a panel host, and we would rather say so here. ## FAQ ### How do files get onto the server without a file manager? **Git or SFTP** — Push to the connected GitHub branch and fortrabbit builds and deploys. For uploads and legacy sites, SFTP and rsync over SSH work with every client, authenticated by key. ### Is there phpMyAdmin? **Not on the server** — The MySQL component is reached over an SSH tunnel with a desktop client such as Sequel Ace or TablePlus, or with a local phpMyAdmin pointed through the tunnel. ### Where do email and domains go? **Elsewhere** — Domains stay at the registrar and point to the environment; fortrabbit issues the TLS certificate. Mail goes through a transactional provider such as Postmark or Mailgun, which is what a CMS password reset needs anyway. --- - [No X](/platform/no-x) - [Public API](/features/public-api) - [MCP server](/features/mcp-server) # Pricing details Source: https://www.fortrabbit.com/pricing/details Published: 2026-03-15 Updated: 2026-07-20 Reviewed: 2026-03-15 > Full machine-readable pricing specs — every component, plan, spec and price (EUR and USD) as tables, plus glossary and billing concepts. # Pricing Source: https://www.fortrabbit.com/pricing Published: 2026-03-15 Updated: 2026-07-21 Reviewed: 2026-03-15 > Pay-as-you-go pricing for PHP hosting — apps are composed from components, each one scales on its own, billed monthly in arrears. ## How pricing works An app environment is composed from components — PHP, MySQL, Storage, Traffic, Backups and Jobs. Each component is booked in a size (XS and up) and scales independently, so the database can grow without touching the PHP plan. The smallest setup starts at €2.50 / $2.50 per month; a small production app with a database lands around €5–€10. Billing is monthly in arrears with daily granularity: a component booked for three days costs 3/30 of its monthly price. Every new app starts as a free trial — no credit card required. Prices are available in EUR and USD. ## Full price list The complete price matrix — every component, every size, both currencies — is maintained at [/raw/pricing/details.md](https://www.fortrabbit.com/raw/pricing/details.md) in machine-readable markdown. The interactive calculator with real-world examples is at [/pricing](https://www.fortrabbit.com/pricing). # Recommend us Source: https://www.fortrabbit.com/recommend-us Published: 2026-03-15 Updated: 2026-07-21 Reviewed: 2026-07-22 # Bolt CMS hosting Source: https://www.fortrabbit.com/software/bolt-cms Published: 2026-03-15 Reviewed: 2026-03-15 > Bolt CMS hosting on a managed PHP platform: a Symfony-based, database-driven CMS deployed with git push, with managed MySQL beside it. Bolt CMS is a modern Content Management System to build websites and thus a better alternative to [WordPress](/wordpress). It's similar to [Craft CMS](/craft-cms), but is built on top of the [Symfony framework](/symfony) (including API Platform for REST and GraphQL) and Twig templating. It's a classical database driven CMS. It's open source AND free. Sadly it does not seem to be maintained any more. Bolt CMS runs well here and fortrabbit is good at PHP hosting. We pride ourselves for being knowledgeable of many PHP software projects, yet Bolt CMS is something we haven't found the time to create an install guide for. You can help. ## FAQ ### Can I host Bolt CMS even without an official guide? **Yes** — We have not written a Bolt-specific guide, but it is a standard Symfony, Twig, and database app, and our Symfony deployment docs map over directly. If you get stuck, our support can help. ### How do I deploy Bolt CMS? **Git push** — Manage it with Composer and deploy with git push; the build runs Composer. Add a MySQL component for its database and keep uploaded files in persistent storage. ### Bolt CMS looks unmaintained — can I still run an older version? **Yes** — Your composer.json pins the version and a matching PHP release is selected per app, so an existing Bolt site stays online. Pick a PHP version the codebase supports. ### Can I try Bolt CMS hosting before paying? **Yes** — Start a free trial — seven days, no credit card — and deploy the Bolt site to see how it runs. ### Can I run Bolt CMS console commands over SSH? **Over SSH** — Full SSH access is included, so the Symfony console and other app commands run directly against the environment. Cron jobs cover scheduled tasks. # CakePHP hosting Source: https://www.fortrabbit.com/software/cakephp Published: 2026-03-15 Updated: 2026-07-21 Reviewed: 2026-03-15 > CakePHP hosting on a managed PHP platform: git-push deploys, Composer on build, managed MySQL and SSH for the console and migrations. CakePHP is a sweet treat for PHP developers. It is an open-source web development framework written in PHP. As a framework it competes with [Laravel](/laravel), [Symfony](/symfony) and others. It's around since 2005 already. Michal Tatarynowicz originally created it, inspired by Ruby on Rails. CakePHP runs well here. It deploys like any Composer-based app: git push, a MySQL component, and the cake console over SSH. The free trial is enough to put a real project on it. ## FAQ ### How do I deploy a CakePHP app to fortrabbit? **Git push** — Push your repository; the build runs Composer and swaps in the release atomically. Add a MySQL component, set env vars in the dashboard, and run the cake console and migrations over SSH. ### Can I host an older version of CakePHP? **Yes** — Your composer.json decides the CakePHP version and the PHP release is selected to match, so a long-running app from an earlier major version keeps working. ### Do you have a CakePHP-specific guide? **It depends** — CakePHP is a standard Composer-based PHP app, so the general deployment docs apply directly. Our support can help with anything specific to the setup. ### Can I try CakePHP hosting before paying? **Yes** — New apps start as a free trial — seven days, no credit card — enough to deploy a real CakePHP project. ### Can I run CakePHP migrations and console commands? **Over SSH** — Full SSH access is included, so the cake console, bake, and database migrations run directly against the environment. Scheduled tasks run as cron jobs. # CodeIgniter hosting Source: https://www.fortrabbit.com/software/codeigniter Published: 2026-03-15 Updated: 2026-07-21 Reviewed: 2026-03-27 > CodeIgniter hosting on a managed PHP platform: git-push deploys, Composer optional, managed MySQL and full SSH access to the app. CodeIgniter is a free and open-source web framework built with PHP. It's simple and flexible. It performs well. It's been around since 2006 and was originally developed by EllisLab (also known for ExpressionEngine). As a framework it competes with [Laravel](/laravel), [Symfony](/symfony) and [Yii](/yii-framework). CodeIgniter runs well here. A lightweight framework doesn't ask for much: a small PHP component covers most projects, with MySQL added when needed. The free trial shows real response times before any payment. ## FAQ ### How do I deploy a CodeIgniter app to fortrabbit? **Git push** — Push your repository; Composer runs in the build and the release is swapped in atomically. Add a MySQL component, set env vars, and use SSH for migrations and Spark commands. ### Can I host an older version of CodeIgniter, like CodeIgniter 3? **Yes** — The framework version is set in the codebase and the PHP version is picked to match, so a legacy CodeIgniter 3 app and a modern CodeIgniter 4 project are both fine. ### Is CodeIgniter fast on fortrabbit? **Yes** — CodeIgniter is lightweight to begin with, and it runs on isolated resources here with OPcache available, so small apps stay quick. Scale the PHP component if traffic grows. ### Can I try CodeIgniter hosting before paying? **Yes** — Every new app starts as a free trial — seven days, no credit card. ### Does CodeIgniter need a database here? **It depends** — Most CodeIgniter apps use a relational database; add a MySQL component for that. A site that stores nothing can run on the PHP component alone. # Craft CMS hosting Source: https://www.fortrabbit.com/software/craft-cms Published: 2026-03-15 Updated: 2026-10-18 Reviewed: 2026-03-15 > fortrabbit hosts Craft CMS sites as managed PHP cloud hosting. Connect a GitHub repo and every git push deploys: Composer runs in the build, then migrations and project config changes run as post-deploy commands. Stack detection recognizes Craft and applies the Craft software template, which sets the build commands, the post-deploy commands, the common environment variables, and the web root path. MySQL and persistent storage for uploaded assets are components to add; SSH access and cron jobs for the queue are included. A PHP version matching composer.json is selected, so a Craft 3 site keeps running while the move to Craft 5 is planned. fortrabbit hosts Craft CMS sites as managed PHP cloud hosting. Connect a GitHub repo and every `git push` deploys: Composer runs in the build, then migrations and project config changes run as post-deploy commands. Stack detection recognizes Craft and applies the Craft software template, which sets the build commands, the post-deploy commands, the common environment variables, and the `web` root path. MySQL and persistent storage for uploaded assets are components to add; SSH access and cron jobs for the queue are included. A PHP version matching composer.json is selected, so a Craft 3 site keeps running while the move to Craft 5 is planned. Craft CMS is a content management system by Pixel & Tonic. Up to version 5 it is based on the [Yii framework](/yii-framework). The code is public on GitHub under Pixel & Tonic's own license, which allows changes to it and asks for one Craft license per production install. Our Craft CMS guides cover local setup, deployment, database and asset syncing, and performance tuning. We have been recognized for Craft hosting since 2019. We have helped many clients to launch and scale their Craft CMS based websites on our hosting platform. :ContactUs if you get stuck or have questions on Craft hosting. We are happy to help. ## FAQ ### How do I deploy Craft CMS to fortrabbit? **Git push** — Deploy code with git push; Composer runs in the build, and migrations and project config changes run as post-deploy commands. The Craft software template sets both up. Keep uploaded assets in persistent storage and add a MySQL component for the database. ### Can I host an older version of Craft CMS, like Craft 3? **Yes** — Your composer.json pins the Craft version and a matching PHP release is selected, so a Craft 3 site keeps running while the move to Craft 5 is planned. Craft's own license terms still apply. ### Does the Craft license cost extra on fortrabbit? **Partially** — Craft CMS is commercial software, and its license is billed by Pixel & Tonic, not by us. fortrabbit charges for hosting and Craft for the license — two separate things. ### Can I try Craft hosting before paying? **Yes** — Start a free trial — seven days, no credit card — and deploy a real Craft site with the help of our Craft guides. ### Can I run Craft console commands and scheduled tasks? **Over SSH** — Full SSH access is included, so craft console commands and migrations run directly against the environment. Scheduled jobs like queue runners are set up as cron jobs. --- - [Why not Servd?](/alternatives/servd) - [Why not Ploi?](/alternatives/ploi) - [Why not Craft Cloud?](/alternatives/craft-cloud) - [Why not Arcustech?](/alternatives/arcustech) - [Agent ready](/workflows/agentic-engineering) # Drupal hosting Source: https://www.fortrabbit.com/software/drupal Published: 2026-03-15 Reviewed: 2026-03-15 > Drupal is a free and open-source content management system (CMS) written in PHP. Think of it as a content creation platform that can be used to create a wide variety of websites, from simple blogs to complex enterprise applications. It's been around for a while, since 2001. Dries Buytaert is the original author. It's a classic LAMP stack application. Drupal is a free and open-source content management system (CMS) written in PHP. Think of it as a content creation platform that can be used to create a wide variety of websites, from simple blogs to complex enterprise applications. It's been around for a while, since 2001. Dries Buytaert is the original author. It's a classic LAMP stack application. There are thousands of modules available for Drupal, so you can customize it to meet your specific needs. It is used by millions of websites around the world, and it has a strong community of developers. It's not the most modern system, but it is surely tried and tested. - Drupal can have a bit of a learning curve, especially if you are not familiar with PHP or web development. - There are a lot of modules available for Drupal, but not all of them are well-maintained. It is important to choose modules that are compatible with your version of Drupal and that have a good reputation. - Drupal can be resource-intensive, so you will need to make sure to book more PHP and MySQL resources. Drupal runs well here. Make sure to book a larger PHP plan. We have a track record for fast, reliable and secure hosting. Try it for free. ## FAQ ### How much PHP and database resource does Drupal need? **It depends** — More than a flat-file site. Drupal and its module stack are memory-hungry, so scale the PHP component up and give MySQL room. Start small on the free trial and scale the components as the site grows. ### How do I deploy Drupal to fortrabbit? **Git push** — Manage Drupal with Composer (the modern drupal/recommended-project layout) and deploy with git push; Composer runs as part of the build. Run drush commands over SSH and keep the public files directory in persistent storage. ### Can I host an older version of Drupal? **Yes** — Your composer.json decides whether the app runs Drupal 9, 10, or 11, with a matching PHP version. That keeps a legacy site live while the upgrade is planned. ### Can I try Drupal hosting before paying? **Yes** — Every new app starts as a free trial — seven days, no credit card — long enough to deploy a real Drupal site and size the resources it needs. ### Can I run Drupal cron and drush over SSH? **Over SSH** — Full SSH access is included, so drush commands run directly against the environment. Set up Drupal's periodic tasks as cron jobs. --- - [Drupal guides](/guides/more/drupal) - [Agent ready](/workflows/agentic-engineering) # Filament hosting Source: https://www.fortrabbit.com/software/filament Published: 2026-10-02 Reviewed: 2026-10-02 > Filament hosting on a managed PHP platform: admin panels and back-office apps on Laravel, with git-push deploys, MySQL, a queue worker and the scheduler. ## About Filament Filament is an open source framework for admin panels, forms and tables, built on [Laravel](/software/laravel) and Livewire. Teams use it for back-office tools and customer portals. ## Filament on fortrabbit A Filament app is a Laravel app, so it deploys with git push. The Filament software template adds the post-deploy steps a panel needs: migrations, the storage link for uploaded files, and the optimize cache. Uploads land on persistent storage and survive every deploy. Imports, exports and queued notifications run on the database queue. A worker job keeps `queue:work` running, a cron job fires the scheduler. Both run on the Jobs component. ## Sizing We deployed a Filament 5 test app with a 500-row CSV import, image uploads and a custom theme. The heaviest request peaked at 10 MiB of memory. A panel needs PHP processes more than memory: their number decides how many requests run at the same moment. ## FAQ ### How do I deploy a Filament app to fortrabbit? **Git push** — Choose the Filament software template and connect the GitHub repo. Every push runs Composer, builds the theme with npm if configured, then runs migrations, storage:link and optimize after the deploy. ### Do Filament imports and exports work? **Yes** — They run on the database queue. Add a worker job for queue:work and a cron job for schedule:run. Running both needs the Jobs SM component. ### Do Filament notifications work without WebSockets? **Yes** — Database notifications work: the panel polls for new ones. Broadcast notifications and Laravel Reverb need WebSockets, which fortrabbit does not support. ### Can I try Filament hosting before paying? **Yes** — Start a free trial — seven days, no credit card — and deploy a real Filament panel. # General PHP Source: https://www.fortrabbit.com/software/general-php Published: 2026-03-15 Updated: 2026-07-21 Reviewed: 2026-03-15 > Plain PHP deploys here like everything else: git push or SFTP, Composer optional, SSH always included. No framework or CMS required. There are many great frameworks in PHP and it's probably fair to say, that PHP is the CMS language. So why still start from scratch when good, well supported abstraction is available? We don't know. Plain PHP deploys here like everything else: git push or SFTP, Composer optional, SSH always included. The free trial handles a single index.php as well as a grown legacy codebase. ## FAQ ### Can I host a custom PHP app with no framework? **Yes** — fortrabbit runs plain PHP as happily as any framework. Point the root path at the public directory, set env vars in the dashboard, and deploy with git push. ### Do I need Composer to deploy raw PHP? **Optional** — Composer is optional. With a composer.json present, the build installs dependencies; without one, the files deploy as they are. Either way, git push is the deploy. ### Which PHP version can I run? **It depends** — The PHP version is chosen per app from the supported range, current and older releases, to match whatever the code needs. ### Can I try it before paying? **Yes** — Every new app starts as a free trial — seven days, no credit card — enough to deploy a custom PHP project and see how it runs. ### Can I run CLI scripts and scheduled tasks? **Over SSH** — Full SSH access is included, so PHP CLI scripts and other app commands run directly against the environment. Recurring scripts run as cron jobs. # Grav hosting Source: https://www.fortrabbit.com/software/grav-cms Published: 2026-03-15 Updated: 2026-09-01 Reviewed: 2026-03-15 > Grav hosting on a managed PHP platform: a flat-file CMS with persistent storage for content and uploads, and no database needed. Grav CMS is a PHP based content management system. It's one of the early flat file systems, like [Kirby](/kirby) and [Statamic](/statamic). Grav CMS is known for its flexibility, making it a popular choice among developers and content creators. There is a wide range of themes and plugins. Grav's flat-file approach keeps the bill small: no database component needed, persistent storage for the content, rsync to sync it. Grav 2.0 needs PHP 8.3 or newer. Try a real site on the free trial. ## FAQ ### Does Grav need a database on fortrabbit? **No** — Grav is flat-file, so a site runs without a MySQL component, which keeps small sites cheap to host. Add a database only if a plugin specifically needs one. ### How do I deploy Grav, and where does content live? **rsync** — rsync carries the whole site and is the shortest route for a flat-file CMS. For a project under version control, git carries the code and rsync carries the content — pages, accounts and uploads stay on the environment, where persistent storage keeps them across deployments. ### Can I host an older version of Grav? **Yes** — Grav 2.0 and 1.7 are both selectable as software version. 1.7 still receives updates and runs on PHP 8.3, so an existing site keeps serving while the move to 2.0 happens on its own schedule. ### Can I try Grav hosting before paying? **Yes** — Start a free trial — seven days, no credit card — and deploy a real Grav site. ### Can I run Grav CLI commands over SSH? **Over SSH** — Full SSH access is included, so the Grav and gpm CLI tools run directly against the environment. Recurring tasks like the scheduler run as cron jobs. # HydePHP hosting Source: https://www.fortrabbit.com/software/hyde Published: 2026-09-04 Reviewed: 2026-09-04 > HydePHP hosting on a managed platform: git push builds the site with Composer and hyde build, and the compiled HTML is served from _site. HydePHP is a static site generator built on Laravel Zero. Markdown files and Blade views go in, plain HTML comes out, written to a folder called `_site`. It is the PHP answer to Jekyll and Astro, and the appeal is the same: a site with no database behind it and nothing to keep patched at runtime. What makes it worth hosting on a PHP platform is the build. Hyde needs Composer and a current PHP version to compile, which is a step most static hosts push onto a separate CI service. Here it is part of the deployment: `git push` triggers Composer, then `hyde build`, then the release swap. The root path points at `_site`, so visitors reach the compiled files. That matters most when the site is not the only thing in the project. A documentation site next to the [Laravel](/laravel) app it documents, a marketing site beside the shop — same provider, same deploy workflow, same SSH access, one invoice. ## What it costs to run Nothing runs between requests, so the component set is small: PHP for the build, plus storage and traffic. No MySQL, no jobs, no key-value store. See the [pricing page](/pricing) for what that adds up to; the install guide covers the deployment settings. Hyde is a young project with a small community. We list it because it works cleanly on this setup and because flat-file publishing has a long history here — the same reasons we support [Kirby](/kirby), [Statamic](/statamic) and [Grav](/grav-cms). ## FAQ ### How does a HydePHP site get deployed here? **Git push** — Push the repository. The build runs Composer and then hyde build, which compiles Markdown and Blade into plain HTML. The root path points at the _site folder that build writes, so visitors reach the compiled output. ### Does a HydePHP site need a database? **No** — Hyde stores nothing at runtime. An app books PHP for the build plus storage and traffic, which is the leanest set of components on offer. ### Why host a static site on a PHP platform? **One place** — Because the generator is PHP. The build needs Composer and a current PHP version, and running it here means the same git push that publishes the site also builds it, with no CI service in between. For a project that already has an app here, it is one provider instead of two. ### Which PHP version does HydePHP need? **8.2 or newer** — Hyde 2 requires PHP 8.2 or newer. The PHP version is set per app and can be raised at any time. ### Can I try HydePHP hosting before paying? **Yes** — New apps start as a free trial — seven days, no credit card. --- - [HydePHP guides](/guides/more/hyde) # Jigsaw hosting Source: https://www.fortrabbit.com/software/jigsaw Published: 2026-09-08 Reviewed: 2026-09-08 > Jigsaw hosting on a managed PHP platform: git push runs Composer and the Jigsaw build, and the compiled HTML is served from the build output. Jigsaw is a static site generator from Tighten, a Laravel consultancy. It renders Markdown and Blade, Laravel's templating engine, into plain HTML, so a finished site has no database behind it and nothing to keep patched at runtime. The build is what makes it worth hosting on a PHP platform. Jigsaw needs Composer and PHP 8.2 or newer to compile, a step most static hosts hand off to a separate CI service. Here it belongs to the deployment: `git push` triggers Composer, then the Jigsaw build, then the release swap. The root path points at the compiled output, so visitors never reach the source. ## What it costs to run Nothing runs between requests, so the component set stays small: PHP for the build, plus storage and traffic. No MySQL, no jobs, no key-value store. The [pricing page](/pricing) has the numbers. Jigsaw fits documentation and product sites that sit beside a larger application. Running both here means one deploy workflow and one SSH login. Flat-file and static publishing has a long history on this platform, which is why [Hyde](/hyde), [Kirby](/kirby), [Statamic](/statamic) and [Grav](/grav-cms) are supported too. ## FAQ ### How does a Jigsaw site get deployed here? **Git push** — Push the repository. The build runs Composer and then the Jigsaw production build, which compiles Markdown and Blade into plain HTML. The root path points at the folder that build writes, so visitors reach the compiled output. ### Does a Jigsaw site need a database? **No** — Nothing is stored at runtime. An app books PHP for the build plus storage and traffic, which is the smallest component set on offer. ### Which PHP version does Jigsaw need? **8.2 or newer** — Jigsaw 1.8 requires PHP 8.2 or newer. The PHP version is set per app and can be raised at any time. ### Why host a static site on a PHP platform? **One provider** — The generator is PHP. Compiling it needs Composer and a current PHP version, so running the build here means the same git push that publishes the site also produces it, without a separate CI service in between. ### Can I try Jigsaw hosting before paying? **Yes** — New apps start as a free trial — seven days, no credit card. # Kirby hosting Source: https://www.fortrabbit.com/software/kirby Published: 2026-03-15 Updated: 2026-06-10 Reviewed: 2026-04-17 > Kirby is a file based CMS made in Germany. Kirby CMS supports modern design patterns and workflows including Composer and support for Git deployment. It's been around since 2012. Founder Bastian Allgeier is a well known figure in the German web scene. We are fans since the early days, specifically of the design language. Kirby is a file based CMS made in Germany. Kirby CMS supports modern design patterns and workflows including Composer and support for Git deployment. It's been around since 2012. Founder Bastian Allgeier is a well known figure in the German web scene. We are fans since the early days, specifically of the design language. It will feel like a fresh breath of air if you come [WordPress](/wordpress). It's more lightweight than [Craft CMS](/craft-cms), yet powerful. It can best be compared with [Statamic](/statamic) and [Grav](/grav-cms), since all of them are file based. Kirby has a super friendly and agile community. We believe that it should get much more praise internationally. Kirby CMS has a welcoming kind-hearted community of tinkerers and builders. Developers, designers and creators meet and help each other on Discord and social gatherings. Kirby CMS is one of the reasons we are building fortrabbit. We aim to support people building websites. We aim to create a platform that offers a good developer experience for hosting Kirby based websites. There are great collaboration workflows and a good documentation. We know a bit about Kirby CMS and are able to support you with chat support setting up your websites. Try it out yourself for free. Spin up a Kirby website in 5 minutes. ## Running on AWS Kirby CMS has strong roots in Germany, and we share that commitment to data sovereignty. Many Kirby users prioritize hosting in Germany or the EU, and we're proud to be based in Germany too. While we selected AWS before current geopolitical discussions, we're committed to transparency about our infrastructure choices. Infrastructure location is just one aspect of the bigger picture. Our billing (Stripe), support (Intercom), and Git integration (GitHub) involve trusted global partners. For a full overview, check our [sub processors list](/legal/data-protection/sub-processors). If data sovereignty is a key concern for you, ! We'd love to hear about your specific needs. Some worries are valid, while others might be based on assumptions. For sites with only public content, data security requirements can vary. There's a lot to consider, and we're here to help. In 2024, we explored Hetzner as an alternative, but ultimately stayed with AWS due to its superior renewable energy profile. Learn more about our [environmental commitment](/environment/our-measures). ## FAQ ### How do I deploy a Kirby site, and where does content live? **rsync/git** — Deploy code with git push; Composer runs in the build if it is used. Content that editors change in the Panel lives in the app's persistent storage and is best synced with rsync. ### Does Kirby need a database here? **No** — Kirby is file-based, so a small site runs without a MySQL component, which keeps it inexpensive to host. Add a database only if the project specifically needs one. ### Is my Kirby site hosted in Germany or the EU? **It depends** — Apps run on AWS in the EU (Ireland), and the company is based in Germany. Many Kirby users care about data sovereignty; reach out to talk through the details, including our sub-processors. ### Can I try Kirby hosting before paying? **Yes** — Spin up a free trial — seven days, no credit card — and have a Kirby site live in a few minutes. ### Can I run Kirby CLI commands over SSH? **Yes** — Full SSH access is included, so the Kirby CLI and other app commands run directly against the environment. Recurring tasks run as cron jobs. --- - [What about privacy?](/benefits/privacy) - [And environment?](/environment/our-measures) - [Why not Hetzner?](/alternatives/hetzner) - [Why not Uberspace?](/alternatives/uberspace) - [Agent ready](/workflows/agentic-engineering) # Laravel hosting Source: https://www.fortrabbit.com/software/laravel Published: 2026-03-15 Updated: 2026-10-17 Reviewed: 2026-03-15 > Reliable Laravel hosting comes down to five checks: queue workers that keep running, a scheduler that fires every minute, deploys that go live only after a successful build, a managed MySQL database, and backups that run without anyone starting them. On fortrabbit, php artisan queue:work runs as a long-running worker and schedule:run as a cron job, both in the jobs component; a worker plus the scheduler needs Jobs SM at a month. A push to the connected GitHub branch runs Composer and npm in a build, and the release goes live atomically, so a failed build leaves the old version serving. MySQL is a separate component that autoscales into the next plan when it fills up. Backups run every 24 hours, from one copy up to 48. SSH covers artisan, tinker and migrations, and the PHP version is picked per environment. Every new app starts a seven-day trial without a credit card. Reliable Laravel hosting comes down to five checks: queue workers that keep running, a scheduler that fires every minute, deploys that go live only after a successful build, a managed MySQL database, and backups that run without anyone starting them. On fortrabbit, `php artisan queue:work` runs as a long-running worker and `schedule:run` as a cron job, both in the jobs component; a worker plus the scheduler needs Jobs SM at €3 a month. A push to the connected GitHub branch runs Composer and npm in a build, and the release goes live atomically, so a failed build leaves the old version serving. MySQL is a separate component that autoscales into the next plan when it fills up. Backups run every 24 hours, from one copy up to 48. SSH covers artisan, tinker and migrations, and the PHP version is picked per environment. Every new app starts a seven-day trial without a credit card. ## Laravel hosting at fortrabbit Laravel is a popular open-source PHP framework that was written and is still being led by Taylor Otwell. It's well on its way to becoming the de facto standard for web application frameworks on the internet. It's easy to get started with, yet powerful. It has a vast ecosystem with many third-party services and additional software built on top of it, such as [Statamic](/software/statamic) and [October CMS](/software/october-cms). Laravel is free open source software. The venture backed Laravel Inc also offers commercial hosting services. We know Laravel well. Our initial platform version was mostly built for Laravel. It was also mostly built with Laravel. Today, we are supporting a wider range of applications. But fortrabbit partly still runs Laravel, side by side with [Symfony](/software/symfony). Installing Laravel on fortrabbit is straightforward: deploy with `git push` and Composer installs the dependencies during the build. Extensive docs you can follow from A-Z including deployment and tuning are at your disposal. Eye to eye developer support is included with the service. fortrabbit's Laravel hosting may cost you less than your current solution. Coming from a dyno-based setup? The [Heroku migration path](/alternatives/heroku) walks through what maps over and what does not. ## FAQ ### How do I choose reliable Laravel application hosting? **Check five things** — Check that queue workers keep running, the scheduler fires every minute, a deploy goes live only after a successful build, MySQL is managed, and backups run without anyone starting them. On fortrabbit, the worker and the scheduler are jobs, the build is atomic, MySQL is its own component, and backups run daily. ### How do I deploy a Laravel app to fortrabbit? **Git push** — Push your repository and the deploy runs Composer, builds the release, and swaps it in atomically. Set env vars in the dashboard, add a MySQL component, and run php artisan migrate over SSH. The git push is the deploy — there is no separate FTP step. ### Can I host an older version of Laravel? **Yes** — Your composer.json pins the framework version with a matching PHP version for the app, so a legacy Laravel 9 project keeps running while the upgrade happens on its own schedule. fortrabbit supports a range of current and older PHP releases. ### Does the Laravel scheduler work on fortrabbit? **Yes** — Add a cron job that runs php artisan schedule:run every minute and the scheduled tasks fire as normal. Full SSH access means artisan commands, tinker, and migrations all work as expected. ### Can I try Laravel hosting before paying? **Yes** — Every new app starts as a free trial — seven days, no credit card. That is enough to push a real Laravel project, connect a database, and check the response times before deciding. ### Does Laravel need a database on fortrabbit? **It depends** — Most Laravel apps use a relational database; add a MySQL component for that. An app that needs no persistence can run on the PHP component alone. --- - [Moving off Heroku?](/alternatives/heroku) - [Why not Laravel Cloud?](/alternatives/laravel-cloud) - [Why not Laravel Forge?](/alternatives/laravel-forge) - [Agent ready](/workflows/agentic-engineering) # Leaf PHP Source: https://www.fortrabbit.com/software/leaf Published: 2026-03-15 Updated: 2026-07-21 Reviewed: 2026-03-15 > Leaf PHP hosting for micro applications and APIs: a lean framework on a small component, deployed with git push, priced for what it uses. Leaf PHP is a new, modern, lightweight PHP framework designed for rapid development of web applications and APIs. Built with simplicity and minimal configuration in mind, Leaf offers a refreshing alternative to large, monolithic frameworks while still providing powerful features like routing, middleware support, and database abstraction. Leaf can be compared Lumen and Slim, as a micro framework. You can use it to build APIs, but is also has an MVC mode. Leaf PHP is developed by the young talent Michael Darko from Ghana. Mind that this is still a new project. It has a vivid community. Installing Leaf PHP on fortrabbit is easy: push the code and Composer resolves the dependencies during the deploy. Our platform is optimized for modern PHP frameworks, making it match Leaf's lightweight architecture. fortrabbit provides good hosting for Leaf applications. With fortrabbit's scalable infrastructure, your Leaf PHP application can handle increased traffic without performance issues. ## FAQ ### How do I deploy a Leaf PHP app or API? **Git push** — Push your repository; the build runs Composer and swaps in the release atomically. Set env vars in the dashboard and add a MySQL component if the app or API needs one. The lightweight setup matches Leaf's minimal footprint. ### Is fortrabbit a good fit for a small Leaf API? **Yes** — A lean Leaf API runs comfortably on a small component, and pricing is component-based, so the bill reflects what the API actually needs. Scale up if traffic grows. ### Can I pin an older version of Leaf? **Yes** — Leaf is a young, fast-moving project; the composer.json pins the version with a matching PHP release, so an app can stay on a known-good version until it is ready to update. ### Can I try Leaf hosting before paying? **Yes** — Every new app starts as a free trial — seven days, no credit card. ### Can I run Leaf console commands over SSH? **Over SSH** — Full SSH access is included, so the Leaf CLI and other app commands run directly against the environment. Recurring tasks run as cron jobs. # Lunar hosting Source: https://www.fortrabbit.com/software/lunar Published: 2026-03-15 Updated: 2026-07-21 Reviewed: 2026-03-15 > Lunar hosting on a managed PHP platform: the Laravel e-commerce package with git-push deploys, managed MySQL and persistent media storage. ## About Lunar Lunar is an open source headless e-commerce solution. It's backend is based on the [Laravel framework](/software/laravel). ## Why fortrabbit Lunar inherits Laravel's deployment story, which is home turf here: git push deploys, migrations over SSH, cron jobs for the scheduler and queues. Start on the free trial and size the components once the store is real. ## FAQ ### How do I deploy a Lunar store to fortrabbit? **Git push** — Lunar is a Laravel package, so the host Laravel app deploys with git push; Composer runs in the build. Add a MySQL component, run migrations over SSH, and drive the scheduler and queues from cron jobs. ### Can fortrabbit handle a Lunar store's load? **Yes** — Size the PHP and MySQL components for the catalog and traffic, and scale them up as the store grows. Pricing is per environment, so staging and production are sized independently. ### Can I host an older version of Lunar? **Yes** — The composer.json pins Lunar and its Laravel base, and a matching PHP version is selected per app, so an existing store keeps running while it upgrades. ### Can I try Lunar hosting before paying? **Yes** — Start a free trial — seven days, no credit card — and deploy a real Lunar store. ### Does Lunar need a database on fortrabbit? **Yes** — Add a MySQL component and configure it like any Laravel app. MySQL is the common choice for a Lunar catalog and orders. # October CMS hosting Source: https://www.fortrabbit.com/software/october-cms Published: 2026-03-15 Reviewed: 2026-03-15 > October CMS hosting on a managed PHP platform: a Laravel-based CMS with git-push deploys, managed MySQL and persistent storage for uploads. October CMS is a modern Content Management System to build websites and thus a better alternative to [WordPress](/wordpress). It has a classical LAMP stack approach. It's open source, but not free. The license costs are however lower than for [Craft CMS](/craft-cms). Like [Statamic](/statamic), October CMS is based on the [Laravel framework](/software/laravel). October CMS has a sibling, [Winter CMS](/software/winter-cms) is a fork. If you're looking to get started quickly, we have some good documentation to help you. When it comes to deployment, we recommend using Git. You can trust us to provide fast, reliable, and secure hosting services. ## FAQ ### How do I deploy October CMS to fortrabbit? **Git push** — October is a Laravel app, so it deploys with git push; Composer runs in the build. Add a MySQL component, run migrations over SSH, and keep uploaded media in persistent storage. ### Does the October CMS license cost extra here? **It depends** — October is commercial software; its license is billed by October, not by fortrabbit. Hosting is paid to fortrabbit and the license to October. The license is cheaper than Craft's, which some teams weigh when choosing. ### Can I host an older version of October CMS? **Yes** — The composer.json pins the version and a matching PHP release is selected per app, so a legacy October site keeps running while the upgrade is planned. ### Can I try October CMS hosting before paying? **Yes** — Every new app starts as a free trial — seven days, no credit card. ### Can I run October CMS console commands and scheduled tasks? **Yes** — Full SSH access covers the October console and Artisan commands, and cron jobs run scheduled tasks and queue workers. # Shopware hosting Source: https://www.fortrabbit.com/software/shopware Published: 2026-03-15 Reviewed: 2026-03-15 > Shopware hosting on a managed PHP platform: git-push deploys, managed MySQL, persistent storage for media and background jobs for orders. ## About Shopware Shopware is a PHP based e-commerce solution from Germany that is around for a while. It's available as a PaaS, SaaS and a free community edition (at [GitHub](https://github.com/shopware/shopware)). ## Why fortrabbit Host the free community edition on fortrabbit to save a a few hundred bucks monthly. ## FAQ ### Can I host the free Shopware Community Edition? **Yes** — That is the common case here. Run the open-source Community Edition on fortrabbit and skip the few hundred per month a managed Shopware plan can cost. Bring the code; fortrabbit provides the hosting. ### Can fortrabbit handle a Shopware shop's load? **It depends** — Shopware is resource-hungry, so scale the PHP component and give MySQL headroom. Add cron jobs for the message queue and scheduled tasks, and scale the components up as catalog and traffic grow. ### How do I deploy Shopware to fortrabbit? **Git push** — Manage the project with Composer and deploy with git push; the build runs Composer, and the Shopware console commands and migrations run over SSH. Media and generated files live in persistent storage so they survive deploys. ### Can I try Shopware hosting before paying? **Yes** — Start a free trial — seven days, no credit card — and deploy a real Shopware Community Edition store first. ### Which database does Shopware use on fortrabbit? **MySQL** — Add a MySQL component for the shop. Give it headroom, since a Shopware catalog and order history are demanding on the database. # Statamic hosting Source: https://www.fortrabbit.com/software/statamic Published: 2026-03-15 Reviewed: 2026-03-15 > Statamic hosting on a managed PHP platform: flat-file or database-driven, deployed with git push, with storage and managed MySQL beside it. Statamic is a modern and highly adaptable CMS that can run full-stack and headless. It's mostly known for being a flat file CMS, but it works with a database as well. It boasts a clean and intuitive interface. Statamic is based on the [Laravel framework](/software/laravel). Statamic is open source, but not free. We have extensive guides to get you started quickly. For deployment we recommend a combination of Git for the code and rsync for the actual contents. We have a track record for fast, reliable and secure hosting. We have been recommended Statamic web host in the past for some time. We don't know why they changed their mind. Specifically small database-less apps are very affordable to host here. ## FAQ ### Should I deploy Statamic content with Git or rsync? **Both** — By role. Deploy code and structural YAML with git push; sync content that editors change in production — entries and assets — with rsync into persistent storage. That keeps deploys atomic without overwriting live edits. ### Does Statamic need a database on fortrabbit? **It depends** — Not for a flat-file setup, which keeps small sites cheap to host here. On the Eloquent driver, add a MySQL component and configure it like any Laravel app. ### Can I host an older version of Statamic? **Yes** — Statamic and its Laravel base are pinned in the composer.json, and the PHP version is selected to match, so a legacy site keeps running while it upgrades on its own schedule. ### Can I try Statamic hosting before paying? **Yes** — Start a free trial app — seven days, no credit card — and deploy a real Statamic site, flat-file or database-backed. ### Can I run the Statamic CLI and scheduled tasks? **Yes** — Full SSH access covers the please and Artisan commands, and cron jobs run the scheduler and any queue workers. # Symfony hosting Source: https://www.fortrabbit.com/software/symfony Published: 2026-03-15 Updated: 2026-08-24 Reviewed: 2026-03-15 > Symfony hosting on a managed PHP platform: git-push deploys, Composer on build, managed MySQL, SSH for console commands and migrations. Symfony is not only a set of PHP components. It's a web application framework, a philosophy and a community — all working together in harmony. The predictable release cycle and the LTS are unique in our fast moving industry. The fortrabbit hosting environment works smoothly with the Symfony framework and with many Symfony based projects. Installing Symfony on fortrabbit is straightforward: a git push deploys the code, and Composer runs as part of the build. We love it too and use it a lot. Some of our backend services are based on Symfony and API Platform. That's why we can give you good support for it. fortrabbit has a track record for fast, reliable and secure hosting. It's less expensive than some more enterprise solutions. A deploy is a `git push`. The build runs `composer install --no-dev`, then whatever the project declares as build commands — `cache:warmup`, `assets:install`, `importmap:install` on an AssetMapper project, or a Webpack Encore production build where the front end needs one. The finished release is swapped in atomically, so a half-written `var/cache` never serves a request. A failed build stops before the swap and the previous release keeps running. Configuration stays out of the repository. `APP_ENV`, `APP_SECRET` and the rest are environment variables set in the dashboard, and the platform injects the credentials of the MySQL component, so Doctrine reaches the database without a secret committed to `.env`. Migrations run over SSH like any other console command. `messenger:consume` and the Symfony scheduler run on the [jobs component](/features/jobs) as worker or cron jobs, in their own processes, away from the web front-end. Scaling happens per component. A Symfony API answering JSON has a different shape from a Symfony site rendering Twig with a heavy back office behind it, and PHP, MySQL, jobs and storage are sized separately — each one moves without touching the others. That also keeps the LTS route affordable: an app pinned to an older Symfony release and a matching PHP version costs the same as one tracking the newest. The Symfony guide in the docs covers the install, the environment variables and the tuning end to end. :ContactUs if something in a specific setup does not line up — the answer comes from people who deploy Symfony here too. ## FAQ ### How do I deploy a Symfony app to fortrabbit? **Git push** — Push the repository; the deploy runs Composer, then build steps like cache:clear and assets:install, and swaps in the new release atomically. Set APP_ENV and secrets as env vars in the dashboard. fortrabbit runs Symfony in its own backend, so the setup is well-trodden. ### Can I host an older or LTS version of Symfony? **Yes** — Symfony's predictable release cycle is one of its strengths, and the composer.json decides the version. Pair an LTS release with a matching PHP version and run it as long as needed; the upgrade happens when it suits the project. ### Do Messenger workers and the scheduler run here? **Yes** — The Symfony scheduler and messenger:consume run from cron jobs, and full SSH access covers console commands, migrations, and debugging as usual. ### Can I try Symfony hosting before paying? **Yes** — New apps start as a free trial — seven days, no credit card — enough to deploy a real Symfony project and check the response times. ### Which database does Symfony use on fortrabbit? **MySQL** — Add a MySQL component and point Doctrine at it via the database env vars. It is the standard relational database here for a Symfony app. ### Do AssetMapper and Webpack Encore builds run on deploy? **Both do** — Node is available during the build, so importmap:install for AssetMapper and an Encore production build both run as build commands. The compiled assets ship inside the release, which keeps the swap atomic and the runtime free of a build step. ### Where do uploaded files go on a Symfony app? **Persistent storage** — The release directory is replaced on every deploy, so anything written at runtime belongs in the mounted storage directory. Point the upload path there — VichUploader, Flysystem or plain move_uploaded_file all work the same way. --- - [Symfony guide](/guides/more/symfony) - [Moving off Heroku?](/alternatives/heroku) - [Why not a VPS?](/alternatives/hetzner) - [Agent ready](/workflows/agentic-engineering) # Tempest PHP Source: https://www.fortrabbit.com/software/tempest Published: 2026-03-15 Updated: 2026-07-21 Reviewed: 2026-03-26 > Tempest PHP hosting on a managed platform: a modern framework deployed with git push, Composer on build, managed MySQL and full SSH access. Tempest PHP is a new PHP framework to build fast and scalable web applications. It emphasizes simplicity, performance, and developer productivity. Tempest provides powerful routing capabilities, a robust middleware system, and comprehensive security features out of the box. The framework follows modern PHP practices and design patterns. It's made by Brent Roose, who is also the well known author of [stitcher.io](https://stitcher.io/). Installing Tempest on fortrabbit is straightforward: push the repository and the build handles the Composer install. A current PHP version per app covers the framework's modern requirements. ## FAQ ### How do I deploy a Tempest app to fortrabbit? **Git push** — Push the repository; the build runs Composer and swaps in the release atomically. Tempest follows modern PHP practices, which the git-push-and-Composer workflow is built around. Set env vars in the dashboard and add a MySQL component if needed. ### Does Tempest run on a recent enough PHP version here? **Yes** — Tempest targets modern PHP, and a current PHP version is selected per app, so the framework's requirements are covered. ### Tempest is new — can I pin a specific version? **Yes** — The composer.json decides the exact Tempest version, so the app can stay on a known-good release as the framework evolves. ### Can I try Tempest hosting before paying? **Yes** — New apps start as a free trial — seven days, no credit card. ### Which database does Tempest use on fortrabbit? **MySQL** — Add a MySQL component and configure Tempest's database connection via env vars. MySQL is the relational database available here. # Twill hosting Source: https://www.fortrabbit.com/software/twill Published: 2026-03-15 Updated: 2026-07-21 Reviewed: 2026-03-15 > Twill CMS hosting on a managed PHP platform: the Laravel-based CMS toolkit with git-push deploys, managed MySQL and persistent storage. Twill is an open source CMS toolkit to own your digital presence. It's based on the [Laravel framework](/software/laravel) and not a classical CMS, but a more professional CMS solution. Twill is Laravel underneath, so the usual workflow applies: deploy with git push, run migrations over SSH, keep media in persistent storage. A free trial is enough to put a real project on it. ## FAQ ### How do I deploy a Twill site to fortrabbit? **Git push** — Twill is a Laravel package, so the host app deploys with git push; Composer runs in the build. Add a MySQL component, run migrations over SSH, and keep media uploads in persistent storage. ### Does Twill need anything special to run here? **No** — No more than a standard Laravel app. Add the database, set env vars, and drive the scheduler and any queues from cron jobs. Media lives in persistent storage so it survives deploys. ### Can I host an older version of Twill? **Yes** — The composer.json pins Twill and its Laravel base, and a matching PHP version is selected per app, so an existing site keeps running while it upgrades. ### Can I try Twill hosting before paying? **Yes** — Start a free trial — seven days, no credit card. ### Which database does Twill use on fortrabbit? **MySQL** — Add a MySQL component and configure it like any Laravel app. Twill stores its content and media references there. # Typo3 hosting Source: https://www.fortrabbit.com/software/typo3-cms Published: 2026-03-15 Reviewed: 2026-03-15 ## About Typo3 Typo3, sometimes stylized as 'TYPO3' or 'Typo 3', is a free and open-source enterprise web content management system. It's from Germany and has been around for a while. It is customizable, flexible and professional. It's popular - specifically in Germany - and there are specialized Typo3 agencies and even a print magazine called t3n. Typo3 can be installed using composer and uses many Symfony components, such as Symfony expression language (SEL). Typo3 has an actively maintained fork called Neos. ## Hosting Typo3 A standard Typo3 is easy to host. It requires a standard LAMP stack which is well supported. The typical Typo3 hosting client is looking for privacy friendly solution, often with local data centers. There are a few Typo3 specialized hosting providers, such as Jochen Weiland and Mittwald hosting. They have a good reputation for Typo3 hosting. ## Why fortrabbit Choose fortrabbit for it's [features](/features). Choose fortrabbit if you want are looking for a more modern setup. We can provide good value for [agencies](/solutions/agency-hosting) and [freelancers](/solutions/freelancer-hosting). ## FAQ ### How do I deploy Typo3 to fortrabbit? **Git push** — Install Typo3 with Composer and deploy with git push; Composer runs in the build. Run the Typo3 console over SSH, add a MySQL component, and keep fileadmin and processed files in persistent storage. ### Where is the data stored — is it in the EU? **Ireland** — Apps run on AWS in the EU (Ireland) and the company is based in Germany. A US region also exists, and several sub-processors are US-based; for the finer points, including the DPA and sub-processor list, get in touch. ### Can I host an older LTS version of Typo3? **Yes** — The composer.json pins the Typo3 version and a matching PHP release is selected per app, so an older LTS site keeps running while the next upgrade is planned. ### Can I try Typo3 hosting before paying? **Yes** — New apps start as a free trial — seven days, no credit card — enough to deploy a real Typo3 site and size its resources. ### Which database does Typo3 use on fortrabbit? **MySQL** — Add a MySQL component for the standard LAMP-style setup Typo3 expects. The fileadmin and processed files belong in persistent storage alongside it. --- - [Typo3 install guides](/guides/more/typo3-cms) - [Agent ready](/workflows/agentic-engineering) # Winter CMS hosting Source: https://www.fortrabbit.com/software/winter-cms Published: 2026-03-15 Updated: 2026-07-21 Reviewed: 2026-03-15 > Winter CMS hosting on a managed PHP platform: git-push deploys, Composer on build, managed MySQL and persistent storage for uploads. ## About Winter CMS Winter CMS is a Content Management System to build websites and thus a better alternative to [WordPress](/wordpress), it is based on the [Laravel framework](/software/laravel). It also has a bigger brother, Winter CMS is a fork of [October CMS](/october-cms). ## Why fortrabbit Winter follows the October and Laravel conventions, and those are well covered here: Composer-based installs, git push deploys, and a MySQL component for the content. Try a real site on the free trial. ## FAQ ### How do I deploy Winter CMS to fortrabbit? **Git push** — Winter is a Laravel application, so it deploys with git push; Composer runs in the build. Add a MySQL component, run migrations over SSH, and keep uploaded media in persistent storage. ### Winter is a fork of October — does it host any differently? **No** — Both are Laravel-based and deploy the same way here. After running October on fortrabbit, Winter will feel identical. ### Can I host an older version of Winter CMS? **Yes** — The composer.json pins the version and a matching PHP release is selected per app, so a legacy site keeps running while the upgrade is planned. ### Can I try Winter CMS hosting before paying? **Yes** — Every new app starts as a free trial — seven days, no credit card. ### Which database does Winter CMS use on fortrabbit? **MySQL** — Add a MySQL component and configure it like any Laravel app. Winter stores its pages and content there. # WordPress hosting Source: https://www.fortrabbit.com/software/wordpress Published: 2026-03-15 Reviewed: 2026-03-15 ## About WordPress No need for introduction. WordPress is the internets's CMS. It ubiquitous and runs everywhere. WordPress is the tool to get job done fast, building a lot of websites for clients. Like many others we started with WordPress early in our career. WordPress is still growing in popularity. The value of the vast ecosystem should not be underestimated. Many of our customers host WordPress projects here alongside with other software. WordPress is free open source software. ## Why fortrabbit fortrabbit hosting shines when it comes to modern tooling and workflows. But the good old basics like SFTP upload are still supported. WordPress is not really made for modern web development, so our Git based deployment workflows will not match. There are forks like Bedrock to modernize the structure. Yet WordPress runs very well on the fortrabbit hosting platform because it's very basic. If you are experienced enough you will actually enjoy that there are no one-click installers or automatic WordPress updates here. There's always a chance of running into an issue that you don't know how to fix. That's where our support comes in. Try fortrabbit hosting by spinning up a free trial app without obligations. ## FAQ ### Can I install WordPress with one click? **No** — And that is on purpose. fortrabbit deploys real code, so WordPress is installed via Composer (or a Bedrock-style setup) or uploaded over SFTP. There is no auto-installer and no forced auto-updates — versions and plugins stay under the app owner's control. ### Where do uploads and the media library live? **Persistent storage** — The code directory is replaced on every deploy, so anything written at runtime — wp-content/uploads and cache files — belongs in persistent storage so it survives releases. ### Is fortrabbit cheap WordPress hosting? **No** — There is cheaper shared hosting if price is the only goal. fortrabbit is built for fast, isolated, well-supported hosting and modern workflows around a WordPress site, not the lowest possible monthly bill. ### Can I try WordPress hosting before paying? **Yes** — Spin up a free trial app — seven days, no credit card — and put a real WordPress install on it. Support is there if a snag comes up; that is a large part of what the price covers. ### Can I run WP-CLI and cron jobs on fortrabbit? **Yes** — Full SSH access covers WP-CLI for installs, updates, and maintenance, and cron jobs handle WordPress scheduled tasks in place of the default page-load cron. --- - [Why not Cloudways?](/alternatives/cloudways) - [Agent ready](/workflows/agentic-engineering) # Yii framework hosting Source: https://www.fortrabbit.com/software/yii-framework Published: 2026-03-15 Reviewed: 2026-03-15 > Yii framework hosting on a managed PHP platform: git-push deploys, Composer on build, managed MySQL and SSH for migrations and console. ## About Yii Its's pronounced "Yee" or [ji:] and it can stand for "Yes It Is!" or in Chinese, "simple and evolutionary". Yii is an object-oriented, component-based framework following the MVC (Model-View-Controller) architecture that runs on PHP. Being a framework, it competes with [Laravel](/laravel) and [Symfony](/symfony). Yii is a versatile framework, applicable to create various web projects like blogs and content management systems (CMS), e-commerce platforms, enterprise applications, web APIs, social networks, forums or any kind of website. Yii is powering other systems such as [Craft CMS](/craft-cms) as well. ## Why fortrabbit Yii runs well here. Make sure to book a larger PHP plan. We have a track record for fast, reliable and secure hosting. Try it for free. ## FAQ ### How do I deploy a Yii app to fortrabbit? **Git push** — Push the repository; the build runs Composer and swaps in the release atomically. Add a MySQL component, set env vars in the dashboard, and run console commands and migrations over SSH. ### How much resource does Yii need? **It depends** — A full Yii application benefits from a larger PHP component, so scale it up and give MySQL room. Start on the free trial and scale the components as the app grows. ### Can I host an older version of Yii, like Yii 1 or 2? **Yes** — The framework version lives in the codebase and a matching PHP release is selected per app, so a legacy Yii 1 or Yii 2 app keeps running. Older versions may need an older PHP version, which can be selected. ### Can I try Yii hosting before paying? **Yes** — New apps start as a free trial — seven days, no credit card. ### Which database does Yii use on fortrabbit? **MySQL** — Add a MySQL component and point Yii's database connection at it via env vars. It is the relational database available here. # Hosting you Source: https://www.fortrabbit.com/solutions/you Published: 2026-02-11 Updated: 2026-08-26 Reviewed: 2026-06-10 > Web hosting for solo developers, indie hackers and side projects — deploy with Git, pay only for what you use, cancel any time. ## Good fit - [Code crafter](/workflows/code-crafting) writing code by hand - [Agentic engineer](/workflows/agentic-engineering) or [vibe coder](/workflows/vibe-coding) - Full stack dev - Web designer - Terminal command line user - Used to modern coding paradigms - Good with Git and Composer - Open to new workflows ## Bad fit - Old code base - Obscure technical requirements - Extra legal requirements - White glove IT support - Custom deal terms or SLAs - Seeking free hosting ## FAQ ### Do I need to know Git to use fortrabbit? **It helps** — Deployment works with git push, so basic Git knowledge helps a lot. You can also use SSH and SFTP. If you are comfortable with a terminal, you will feel at home. ### Is fortrabbit good for beginners? **It depends** — Novice developers and students who want to learn modern workflows are welcome. Absolute beginners looking for FTP-only or free hosting will be happier elsewhere. ### Can I try fortrabbit for free? **Yes** — Spin up a free trial — seven days, no credit card — and see if it works for you. ### What software can I host? **PHP** — PHP in all flavors: Craft CMS, WordPress, Statamic, Kirby, Laravel, Symfony and more. See the supported software pages for details. ### Can I cancel any time? **Yes** — Cancellation runs through the dashboard and takes effect immediately. There is no lock-in and no long-term contract. --- - [No xyz here](/platform/no-x) - [Our culture](/us/culture) - [Our history](/us/history) # Freelancer hosting Source: https://www.fortrabbit.com/solutions/freelancer-hosting Published: 2026-03-15 Updated: 2026-08-23 Reviewed: 2026-07-20 > Managed PHP hosting for freelance web developers — small-site pricing, post-paid billing, client handover and hosting resale in one account. A freelance web developer runs the whole company alone: development, operations, project management, invoicing — and answering the phone when a client thinks the site is down. Hosting touches every one of those jobs. It decides how many hours a month go into work that never appears on an invoice, what a small client is asked to pay for a small site, and how gracefully a project changes hands when the work ends. We have sat on that side of the table ourselves [in the past](/us/history) — this platform is the hosting we wanted back then. It runs the software freelance projects are built with: [Craft CMS](/software/craft-cms), [Kirby](/software/kirby), [Statamic](/software/statamic), [Laravel](/software/laravel), [WordPress](/software/wordpress) and [more](/software). ## Unbillable hours are lost income An employed developer who spends an afternoon patching a server costs the employer some money. A freelancer who spends the same afternoon has lost the income directly — server care is the textbook case of work no client sees and no client wants to pay for. Here, the platform layer is our job: operating system, web server, PHP runtime and MySQL are operated and kept current by us. The application stays under the developer's control — we deliberately [do not update installed software](/platform/no-x), because nobody wants a CMS update they did not schedule landing in the middle of a client launch. [TLS certificates](/features/free-certificates) for custom domains are issued and renewed automatically, at no charge, so certificate renewals disappear from the calendar entirely. There is also no colleague down the hall. When something is unclear, [support](/benefits/get-support) is a direct chat with the people who operate the platform — no outsourced first level. The median first response is under two hours during business hours (CET). That is not a 24/7 promise, and we say so. It is a second pair of experienced eyes for a business that otherwise has exactly one. ## Priced for what a small client will pay A small business site only supports a small hosting bill, and the freelancer is the one who has to defend that line item. Pricing here is [component based](/pricing/details): PHP, traffic and storage are required, everything else — MySQL, backups, jobs — is booked only where a project needs it. The smallest possible combination starts at €2.50 per month, and the smallest traffic plan covers 96% of websites, so a brochure site does not subsidize capacity it will never use. There are no per-seat charges and no feature tiers on top. Collaboration — teams, invited people, shared payment methods — is included at no extra cost, so bringing a client into the dashboard or a colleague into a project never changes the bill. The bill follows the app's resource usage, not the size of the business around it. Current numbers live on the [pricing page](/pricing). ## The long tail of old client sites Years of freelancing accumulate a trail of small sites that still matter to their owners but barely justify their keep. Component pricing lets each of those apps shrink to what it actually does: pick the smallest PHP plan, drop the components that are not used, and the site idles at a price its owner will accept. [Autoscaling](https://docs.fortrabbit.com/platform/billing/autoscaling) is optional per environment — switched off, the price is fixed, with the honest trade-off that an app exceeding its booked plan goes offline rather than quietly costing more. An email warning goes out before a limit is reached. Billing is pro-rated by the day, so a site retired today stops costing anything tomorrow — and with a local backup in hand, it can be redeployed into a fresh app later if the owner changes their mind. The [reduce hosting costs guide](https://docs.fortrabbit.com/dev/how-to/reduce-hosting-costs) walks through trimming a portfolio app by app. ## Cash flow in the right order Prepaying a year of hosting on behalf of a client is an interest-free loan to that client — one a one-person business is badly positioned to give. There are no upfront payments here at all: billing is post-paid, calculated after usage, invoiced monthly in arrears, with a minimum billing period of one day. Hosting costs land after the work they belong to, roughly when the client's own invoice does. There is no minimum contract term, and [cancellation](/benefits/cancel-any-time) takes effect immediately — a project that dies mid-month is billed for the days it existed, not for the quarter it was supposed to last. ## Resell hosting or let the client pay directly Both models are legitimate; which one fits depends on the client and on the appetite for sitting in the billing chain. Apps here are owned by [payment methods](/benefits/collaborate), not accounts, which supports either choice cleanly. To resell, keep the app on a payment method of the business and invoice the client — margin and terms are the freelancer's own affair. To step out of the money flow, the client attaches their own payment method and pays us directly, while deploy and SSH access stay granted per person and per app, separately from ownership. Switching from one model to the other mid-month does not bill anyone twice, since daily pro-rated billing splits the month at the day of the change. There is a [page for the client](/solutions/client) that explains their side in their language. ## Being the only one on call When a client site breaks at 2 am, a freelancer has no rotation to escalate to. Nothing removes that entirely, and we will not pretend otherwise — but the platform shrinks the list of things that can page one person. The infrastructure is monitored around the clock with on-call duties on our side, backed by a 99.5% uptime SLA, so a failing server is our night shift, not the developer's. What remains in one person's hands is the application itself, which is the part that person knows best. The optional [backups component](/features/backups) adds restore points for the days when the fastest fix is going back to yesterday. ## Stopping without abandoning the client Every maintenance arrangement ends eventually — a career change, a full order book, or a client who has outgrown a one-person setup. The exit does not have to strand anyone. Ownership of an app can [change hands](/benefits/hand-over) without the app moving: code, database, domains and certificates stay where they are while billing and responsibility transfer to the client or to a successor. Access works the other way around too — it can be revoked, or granted to the next developer, without touching the running site. The client keeps their website either way. And when the direction of growth is the opposite one — more work than one person can carry — the team side of the same machinery is covered on the [agency page](/solutions/agency-hosting). ## Migration is self-service, on purpose We do not migrate sites on anyone's behalf — [no free migrations](/platform/no-x) is a stated principle, not an oversight. A migration performed by somebody else leaves nobody who understands it afterwards, and for a site whose entire maintenance department is one person, that person needs to know where everything lives. The way in is documented: the [migration guide](https://docs.fortrabbit.com/dev/how-to/migrate-to-fortrabbit) covers the general path, the [alternatives pages](/alternatives) carry cutover notes per provider, and support is reachable throughout. The free trial takes the risk out of trying: every new app starts a [seven-day trial](/benefits/try-free), no credit card required, so a copy of a client site can run here and be shown live before anything is cancelled at the old host. ## FAQ ### Can I manage multiple client projects with one account? **Yes** — One login connects to multiple apps, teams and payment methods. Collaboration features map real-life business relations — code access and billing included. ### Can I hand a project over to my client? **Yes** — Transfer the app when the project is done. The client takes over billing and ownership, and can grant continued code access for maintenance. ### What does freelancer hosting cost? **It depends** — Pricing is component based and post-paid, with a one-day minimum billing period. The smallest possible combination starts at €2.50 per month. See the pricing page for real-world examples. ### Can my client pay fortrabbit directly? **Yes** — Apps are owned by payment methods, not accounts. A client can attach their own payment method and pay directly, while the developer keeps deploy and SSH access. ### Can I try fortrabbit before paying? **Yes** — Every new app starts a free trial — seven days, no credit card required. A copy of a client site can go live for review before anything is committed. ### Are there spending limits? **Yes** — Autoscaling can be turned off and a specific plan picked, so an app stays within a set budget instead of scaling on its own. ### Do you migrate my sites for me? **No** — Migration is self-service by design, with a step-by-step guide and reachable human support. Whoever performs the migration understands the hosting afterwards. --- - [Collaborate](/benefits/collaborate) - [Hand over](/benefits/hand-over) - [For the client](/solutions/client) - [Migration guide](/dev/how-to/migrate-to-fortrabbit) # Agency hosting Source: https://www.fortrabbit.com/solutions/agency-hosting Published: 2026-03-15 Updated: 2026-10-17 Reviewed: 2026-07-20 > Hosting for web agencies — team access control, per-client ownership and billing, staging environments and clean client handovers. Production PHP since 2012. fortrabbit is agency hosting for PHP teams that maintain many client sites while their staff changes over the years. Developers sign up personally and join the agency's team with an unlimited or a limited role, and a freelancer can be invited to a single app without joining the team. Each client project is an app, billed to a payment method with its own invoice address and VAT settings, so one login covers every client while each client gets a separate bill. An app holds a production and a staging environment, each deployed from its own Git branch, with password protection for client reviews and smaller components on staging to keep it cheap. At handover, the client's payment method takes over billing and the app stays where it is: no migration, no redeploy, and the agency keeps developer access for maintenance. Removing a person from the team ends their access in one step. Teams, invites and payment methods cost nothing extra. fortrabbit started inside a web agency before becoming its own company [in 2012](/us/history). The stacks agencies build with — [Craft CMS](/software/craft-cms), [Statamic](/software/statamic), [Laravel](/software/laravel) and [more](/software) — get dedicated guides and support here. ## One login, all client projects Sign-up is personal — an account represents a real person, not a company. From there the structure is many-to-many: a team groups the agency's developers, apps represent the client projects, and each app is owned by a payment method rather than by whoever happened to create it. One login shows every client project, while each project keeps its own owner and its own bill. That separation sounds bureaucratic until the day two clients part ways with the agency in the same quarter. Because ownership, access and billing are independent objects, each relationship can be unwound on its own — no shared account to split up, no innocent bystander sites affected. The [collaboration features](/benefits/collaborate) exist precisely to map these real-world business relations. ## Access that survives staff changes People join, people leave, contractors come in for one project. There are two [team roles](https://docs.fortrabbit.com/platform/collaboration/team-roles): unlimited for the core team — full access to apps, members and billing — and limited for junior developers or externals, scoped to chosen apps. Freelancers who help out on a single project don't need to join the team at all; they can be invited to that one app directly. Offboarding is the part most setups get wrong. Here, removing a person from the team ends their dashboard access and their personal code access in one step. Nothing about the apps changes: no deploy keys to swap, no redeployment, no downtime. The same works in reverse — anyone can leave a team on their own, and the apps stay behind with the team. Compare that with the industry default of a shared master login whose password has to be rotated after every departure, and usually isn't. ## Whose name is on the invoice A payment method is its own object with an invoice address, VAT settings and a separate invoice archive. An agency can hold several of them — one per client, one for internal projects — and route each app's charges accordingly, all managed from the same login. That makes the resell-or-pass-through question a choice instead of a constraint. An agency that bundles hosting into a retainer keeps the apps on its own payment method and re-bills as it sees fit. An agency that wants hosting out of its books puts the client's payment method in charge: the invoice then carries the client's name and address, goes into the client's archive, and the agency keeps developer access for maintenance. No invoices forwarded with a markup nobody asked for, no client paying for a service they cannot see. Switching between the two models later is a [handover](/benefits/hand-over), not a migration. Ownership changes while code, database, domains and certificates stay put, and pro-rated daily billing means a mid-month transfer is not paid twice. There is even a [page to send clients to](/solutions/client) that explains their side of the arrangement. ## When the developer who built it leaves The uncomfortable agency question: a client site was built four years ago by somebody who has since left. Who can still deploy it? No platform can transfer application knowledge that was never written down — but the infrastructure side can be made self-describing instead of living in one person's head. The platform pushes in that direction. Configuration belongs in environment variables, not in code, so credentials survive a personnel change and can be rotated without a deployment. Scheduled work belongs in the jobs component, not in a personal crontab. Uploads belong in the storage component, not on somebody's disk. An app built this way is documented by its own dashboard: the next developer can read the setup instead of reverse-engineering it. The departure itself is then an access change, not an incident. ## A staging environment per client project Each app has at least one environment, and every environment is a fully isolated hosting setup with its own settings, domains and individually billed components. An environment can be mapped to a Git branch, which turns a client project into the familiar shape: a production environment on the main branch, a [staging environment](/features/staging-environments) on a develop branch for reviews and client demos. Staging does not have to cost like production. Smaller component sizes keep a review environment cheap, built-in [password protection](https://docs.fortrabbit.com/platform/settings/password-protection) keeps it away from public eyes and search engines, and daily billing means an environment deleted after launch stops costing anything the next day. Concepts and workflows are covered in the [multi-staging guide](https://docs.fortrabbit.com/dev/learn/staging-environments). ## Reliability an agency signs its name to When a client site goes down, the client calls the agency — the reputational risk of the hosting choice sits with whoever recommended it. The platform runs on [AWS infrastructure](/platform/infrastructure), environments are isolated from each other so one busy site cannot starve another, and a [99.5% uptime SLA](/legal/contract/service-level-agreement) with defined service credits backs it up. The platform is monitored around the clock with on-call duties. Each app runs in a chosen region — EU (Ireland) or US — picked once per app to match where the client's audience is. Support is part of that calculation. It runs through chat during business hours (CET), staffed by the people who operate the platform, with a median first response of under two hours. There is no phone line and no white-glove tier — see [what fortrabbit deliberately does not do](/platform/no-x). And because provider longevity is itself a client-relationship risk, it is worth knowing that the same independent German company has operated this service since 2012 and publishes its [cost breakdown](/us/cost-breakdown), down to a 4% profit margin. ## Margin without seat licenses On the old platform, team features were a paid add-on — company plans ran up to $250 per month for a large organization. The new platform includes all collaboration features at no extra cost: teams are free, inviting people is free, payment methods are free. Costs scale with what the client apps actually consume, not with the agency's headcount or project count. The billing model follows through. Components are booked per environment, billed pro-rated and post-paid with a one-day minimum; the smallest possible combination starts at €2.50 per month. [TLS certificates](/features/free-certificates) for client domains are included and renew automatically. Autoscaling is optional and can be capped, so a fixed-budget client site stays inside its budget. There is no minimum contract and hosting can be cancelled at any time — full numbers and worked examples live on the [pricing page](/pricing) and in the [pricing details](/pricing/details). ## Migration is self-service, on purpose There is no free migration service here, and that is a [deliberate decision](/platform/no-x), not a gap in the offer. A migration performed by the provider leaves nobody at the agency who understands it afterwards, which is a poor trade for a team that will maintain the site for years. The [migration guide](https://docs.fortrabbit.com/dev/how-to/migrate-to-fortrabbit) covers the general procedure, the [alternatives pages](/alternatives) carry provider-specific notes, and support is reachable throughout with specific questions. The free trial makes the rehearsal cheap: every new app starts with [seven days of full access](/benefits/try-free), no credit card required, so a first client project can be stood up and tested before any DNS record changes. ## FAQ ### How does collaboration work for a web agency? **Teams and roles** — Developers join a team with an unlimited or limited role, external contractors can be invited to single apps. One login covers all client projects, and access ends cleanly when somebody leaves. ### Can hosting and billing be transferred to a client? **Yes** — An app changes owner without moving. The client's payment method takes over billing while the agency keeps developer access for maintenance. No migration, no downtime, nothing to re-test. ### What happens when a developer leaves the agency? **Revoke access** — Removing a person from the team ends their dashboard access and personal code access. The client apps keep running untouched — nothing needs to be moved or redeployed. ### Does hosting have to be resold to clients? **No** — Both models work. The agency pays and re-bills hosting as part of a retainer, or the client's own payment method owns the app and receives the invoice directly. ### Is fortrabbit reliable enough for client production sites? **Yes** — Apps run on AWS in isolated environments, backed by a 99.5% uptime SLA and around-the-clock monitoring. We have been hosting production PHP sites since 2012. ### Which software is supported? **PHP** — The PHP stack agencies build with: Craft CMS, WordPress, Statamic, Laravel and more. Deployment via Git with Composer support is built in. ### Is there root access on the servers? **No** — This is a managed platform, not a VPS. Deployment runs via git push, Composer resolves dependencies, and SSH access covers day-to-day work. --- - [Client hand over](/benefits/hand-over) - [Team collaboration](/platform/collaboration) - [Developer support](/benefits/get-support) # Startup hosting Source: https://www.fortrabbit.com/solutions/startup-hosting Published: 2026-03-15 Updated: 2026-08-23 Reviewed: 2026-07-20 > Hosting for PHP startups — ship an MVP without a DevOps hire, keep burn tied to usage, scale components when traction arrives. Honest about the ceiling. A startup before product-market fit has one engineering priority: find out whether anyone wants the product. Every hour that goes into provisioning servers, tuning deploy scripts or reacting to a disk-full alert is taken from that question — and it burns runway all the same. At fortrabbit the platform layer is our job and the product is the team's, a split we have operated since 2012 for the frameworks startups build on: [Laravel](/software/laravel), [Symfony](/software/symfony), [Tempest](/software/tempest) and [more](/software). And because a hosting pitch should survive contact with growth, this page also says plainly where the platform stops fitting. ## The DevOps hire that can wait Hiring an infrastructure engineer before revenue means paying one of the most expensive salaries on the market to keep servers alive for users who may not exist yet. The usual workaround — the founding developer runs operations on the side — costs more than it looks, because infrastructure work is interrupt-driven: it arrives as kernel advisories, full disks and expiring certificates, and it fragments exactly the focused weeks an unshipped product needs. The division of labor here is explicit. We operate the platform — operating system, web server, PHP runtime, MySQL — and keep it patched and monitored around the clock; the team stays responsible for the software it writes and deploys. The deploy pipeline comes with the platform instead of being built by hire number one: connect the repo through the [GitHub integration](/features/github-integration), push a branch, and dependencies are installed and artifacts built on our side, with settings that allow deployments without downtime. A first technical hire inherits working infrastructure and gets to work on the product. ## Burn that follows usage, not a contract A hosting line in a burn table should move with product usage, not with a contract date. Billing is component-based and post-paid, pro-rated with a one-day minimum: PHP, traffic and storage are required, while MySQL, the jobs component and backups are booked only where the product needs them, each sized in its own small steps. The smallest possible combination starts at €2.50 per month, so a landing page validating an idea is not priced for the success case. Nothing is paid upfront and there is no minimum term — the hosting number in this month's burn is what the product consumed this month. Two things never show up in that number. Collaboration carries no charge — teams, invited people and payment methods are free, so headcount growth does not leak into the hosting bill. And there are no feature tiers to be pushed up from: cost follows load and data, nothing is gated behind a bigger plan. For a hard budget line, [autoscaling](https://docs.fortrabbit.com/platform/billing/autoscaling) can be switched off per environment, trading elasticity for a fixed price. Worked examples live on the [pricing page](/pricing) and in the [pricing details](/pricing/details). ## An experiment should be cheap to end Most startup code is written to be thrown away — that is what validated learning means in practice. Hosting rarely cooperates: a test server set up for a killed feature tends to keep running because nobody remembers why it exists, and a prepaid plan keeps billing for a pivot that already happened. Environments here map to that workflow. Each app carries any number of environments, every one an isolated hosting setup with its own Git branch, own domains and individually sized components. A risky feature branch gets a small environment for the days it is under review, a [staging environment](/features/staging-environments) mirrors production for the release candidate, and the [multi-staging guide](https://docs.fortrabbit.com/dev/learn/staging-environments) covers the patterns. Deleting an environment removes it within minutes, files and database included — and with daily pro-rated billing, an environment deleted on Tuesday is off the invoice from Wednesday. The same holds one level up. Every new app begins with a [free trial](/benefits/try-free): seven days, all components available in all sizes, no credit card required. A proof of concept can be built, demoed to an investor and discarded without ever producing an invoice — and the next idea starts a fresh trial. ## Traction without re-platforming Elsewhere, growth tends to mean a bigger box and a maintenance window. Here it is a plan change: each component scales individually from the dashboard, takes effect right away, and nothing moves. Traffic, storage and MySQL autoscale by default — a spike books the next plan up, and the booking steps back down once the wave passes. PHP does not autoscale, deliberately, because PHP load patterns are too individual for a safe automatic signal; it is scaled by hand, from XS up to 2XL. Equally important is the direction of scaling. Components move independently, so customer growth that needs more PHP processes does not force a bigger database, and the other way around — spend follows the actual bottleneck. What a subscription product looks like on this platform in practice — billing runs in workers, one database per environment, polling instead of push — is covered on the [web app use case page](/use-cases/web-app-hosting). One choice does not scale later: the region. It is picked per app — EU (Ireland) or US — and cannot be changed afterwards, so it should follow where the first paying users will be. ## Where the ceiling is A platform pitch that claims to fit forever is lying to somebody. This is a managed PHP platform, and its shape has edges. There is no root shell and no way to install system software — anything beyond PHP, from FFmpeg to Node, is out. There is no Redis component; in-process caching falls to OPcache and APC, while queues run through the database with workers in the [jobs component](/features/jobs). Persistent connections are not supported, so WebSocket features — live dashboards, collaborative editing, chat — need polling or a third-party service. And an app lives in exactly one region. For the stretch between first deploy and serious scale, these edges rarely bind: the XS and S PHP plans already cover most ordinary workloads, and the range tops out at eight parallel PHP processes on the largest plan. But a product whose roadmap depends on Redis-backed realtime features, kernel-level tuning or multi-region infrastructure has outgrown this platform — and will by then usually have raised the team that runs raw cloud infrastructure. Reaching that ceiling is the good outcome. The full list of edges is on [no X](/platform/no-x) and in the [limits docs](https://docs.fortrabbit.com/platform/concepts/limits). ## Answers for the due-diligence deck At some point an investor, an accelerator checklist or a first enterprise customer asks about vendor risk, and "a PaaS we found" is a weak answer. The facts here are public. fortrabbit has operated since 2012 as the first European platform as a service built specifically for PHP — bootstrapped, and still owned by the same independent Berlin company whose [history](/us/history) goes back to 2004. Apps run on [AWS infrastructure](/platform/infrastructure), backed by a [99.5% uptime SLA](/legal/contract/service-level-agreement) with defined service credits. And the business is profitable rather than growth-funded: the [cost breakdown](/us/cost-breakdown) is published, down to the 4% margin. A vendor that does not depend on its next funding round is one less dependency that can fail at the same time as everything else. The exit path is equally checkable. The stack is standard PHP, MySQL and Git: the code already lives in the team's own repository, the database leaves as a plain mysqldump, files leave over SFTP, and there is no minimum contract term to buy out of. Ending the dependency takes an afternoon. ## When the team arrives The first hires change what the account has to do, not where the app runs. Collaboration is built in and free of charge — the mechanics of teams, roles and per-app access for contractors are on the [agency page](/solutions/agency-hosting), the underlying model under [collaborate](/benefits/collaborate). And if the exit is the happy one — an acquisition, or the product moving in-house somewhere — ownership of an app [changes hands](/benefits/hand-over) without the app moving. What was founder-built becomes team-run by granting access, not by re-hosting. ## FAQ ### Does fortrabbit scale with a startup? **Per component** — Components scale individually from the dashboard and changes apply right away. Traffic, storage and MySQL can autoscale automatically; PHP is scaled by hand. Growing from MVP to product never requires moving the app. ### Is fortrabbit a good fit for a Laravel SaaS? **Yes** — Git deployment, Composer builds, queue workers and cron jobs in the jobs component, and staging environments are all built in — the parts a subscription product needs around the code. ### Can each feature branch get its own environment? **Yes** — Environments map to Git branches. Each one is an isolated setup with its own components, sized small for testing, and deleting it after the merge ends its billing with the day. ### Can spending be capped while iterating? **Yes** — Autoscaling can be switched off per environment for a fixed price. An environment that exceeds its booked plan then goes offline instead of costing more — a warning e-mail goes out before. ### Is there a forever-free tier? **No** — Every new app starts a seven-day free trial with all components in all sizes, no credit card required. After that, billing is component-based, post-paid and pro-rated by the day. ### What is not supported? **A few things** — No root access, no Redis component, no WebSockets, and a fixed region per app. This is a managed PHP platform, not a VPS — the limits are documented, not hidden. ### How hard is it to leave? **Not hard** — The stack is standard PHP, MySQL and Git. Code lives in the team's own repository, the database exports as a plain mysqldump, files copy out over SFTP, and there is no minimum contract. --- - [Scale on demand](/benefits/scale-on-demand) - [Web app use case](/use-cases/web-app-hosting) - [What we don't do](/platform/no-x) - [Multi staging guide](/dev/learn/staging-environments) # For the boss Source: https://www.fortrabbit.com/solutions/boss Published: 2026-03-15 Updated: 2026-08-23 Reviewed: 2026-07-20 > Vendor due diligence on fortrabbit — independent since 2012, published cost breakdown, 99.5% SLA, EU or US data regions, no lock-in. For decision makers. Hosting requests rarely start with the person who signs. The developers pick a platform, make their case, and then somebody with budget responsibility has to approve a vendor they may never have heard of. This page is for that somebody. The developer arguments live elsewhere on this site — what follows are the procurement answers: who runs this company, what the real exposure is, where data sits, how the cost behaves over time, and what leaving would look like. ## Will this vendor exist in five years That is the first honest question about any small vendor, so it goes first. fortrabbit has operated since 2012, owned and run by the same independent company — a GmbH registered in Berlin, with roots in internet services going back to 2004. It was the first European platform as a service built specifically for PHP, and it still does that one thing. The company is bootstrapped: there are no investors to satisfy, so there is no pressure to inflate growth, sell the business or raise prices to meet a valuation. The [company history](/us/history) is published including the slow years — a fourteen-year-old business that documents its own plateaus carries a different risk profile than a funded startup whose hosting product must grow or die. ## The books are open Most vendors ask to be trusted on pricing; this one shows the ledger. The published [cost breakdown](/us/cost-breakdown) states where revenue goes: 44% people, 33% infrastructure, 10% sub-processors, 2% marketing, 1% donations, 1% irregular expenses — and a 4% profit margin. Two of those numbers matter for a buying decision. The 2% marketing share means the price funds operations rather than customer acquisition. And the 4% margin means the service is priced to sustain itself, not to maximize a valuation — a company living on 4% cannot afford to lose long-term customers to short-term price games. ## The exposure, in writing The uptime commitment is a written [service level agreement](/legal/contract/service-level-agreement), not a marketing figure: 99.5% general uptime, with service credits proportional to actual downtime and capped at the monthly fee. The number is set conservatively and the conditions are published in full — including the standard limitation that no hosting provider accepts liability for consequential damages, which is better read now than discovered later. Underneath, apps run on [AWS infrastructure](/platform/infrastructure) in isolated environments, so one busy application cannot starve another. What does not exist: custom SLAs. The terms are the same for every customer, which is part of why the price is what it is. ## Where the data sits, and who else touches it Each app runs in a region chosen at creation — EU (Ireland) or US — and account and billing data is stored in Ireland. The contracting party is a German company, contracts are governed by German and European law, and the GDPR [data processing agreement](/legal/data-protection/data-processing) is part of the terms of service: it applies automatically, with nothing separate to sign. Every [sub-processor](/legal/data-protection/sub-processors) that handles data is listed publicly and assessed for GDPR compliance. One caveat belongs here rather than in the fine print: this is not a sovereign cloud. The infrastructure is AWS and several sub-processors are US companies, so the US CLOUD Act can apply. What is on offer is transparency about exactly that — the full vendor-assessment picture sits on the [trust page](/trust). ## How the cost moves Billing is component based and post-paid: an app books the resources it needs, usage is billed pro-rated by the day, and the invoice arrives after the period it covers. There are no per-seat licenses and no feature tiers — adding people, teams or payment methods never changes the bill, so cost follows the workload rather than the org chart. Spending can be capped: autoscaling is optional, and with a fixed plan an app cannot quietly outgrow what was approved for it. There is no minimum term and nothing is paid upfront. The smallest possible setup starts at €2.50 per month; current numbers and worked examples live under [pricing](/pricing) and [pricing details](/pricing/details). ## Nothing proprietary to be trapped by Lock-in risk is a function of proprietary surface, and there is little of it here. The stack is standard PHP, MySQL, Git and Composer — no vendor-specific framework, no proprietary database, no installer format that exists only on this platform. An application that runs here runs on any comparable host: the code lives in the team's own Git repository, the database exports with standard tools, and the domain points wherever DNS says. [Cancellation](/benefits/cancel-any-time) works from the dashboard with immediate effect and no termination fee; billing stops the same day. The same openness applies on the way in — migrations are [not performed on anyone's behalf](/platform/no-x), as a stated principle, so the developers who move an application here will be the ones who understand where everything lives. ## Accountability when something breaks Responsibility is split along a named line: we operate and secure the infrastructure and the stack; the application code on top stays with the developers who wrote it. That line is policy, not fine print: when something fails, the layer says whose problem it is. [Support](/benefits/get-support) runs through chat, answered by the same small team that operates the platform — there is no first-level call center to get past. The median first response is under two hours during business hours (CET), and most cases are resolved within a day. Infrastructure failures are not support tickets: monitoring runs around the clock, with humans on call behind it, independent of chat hours. ## Why not the provider nobody gets fired for choosing The safe answer to any hosting decision is a hyperscaler, and the comparison is fair to raise — fortrabbit itself runs on AWS. The question is who operates the platform on top. Using AWS directly means someone in-house owns a hundred-service console, the cost spreadsheet, the patching and the 3 am pages — capability that is bought as headcount. What fortrabbit sells is that operations layer as a service: managed middleware on AWS, priced so the honest comparison is not against the AWS invoice, but against the AWS invoice plus the fraction of an engineer who tends it. ## What is not on offer A procurement checklist will surface these anyway, so here they are up front. Nobody here answers a phone, and there is no premium support tier to buy. There are no custom contracts, negotiated terms or individual SLAs — the service is standardized self-service, and we do not keep a legal team to redline vendor agreements. fortrabbit holds no SOC 2 report and no own ISO 27001 certificate (the AWS infrastructure underneath is certified); there is no HIPAA BAA, so regulated health data is out of scope. There is no root access, because this is a [managed platform, not a rented server](/platform/no-x). Any of these can be a legitimate deal-breaker — better found on this page than after signature; the [compliance page](/legal/standards/compliance) answers the usual questionnaire items in the same spirit. For everything else, the cheapest due diligence is the [free trial](/benefits/try-free): seven days, full feature access, no credit card — run by the developers who started this conversation. ## FAQ ### How long has fortrabbit been in business? **Since 2012** — The same independent German company has owned and operated the service since 2012, with roots in internet services going back to 2004. Bootstrapped, no outside investors. ### What about vendor lock-in? **None** — No long-term contracts, cancel at any time with immediate effect. The stack is standard PHP, MySQL, Git and Composer, so moving away is as easy as moving in. ### Where does my data live? **It depends** — Each app runs on AWS in a region chosen at creation — EU (Ireland) or US. Account and billing data is stored in Ireland. Every sub-processor is publicly listed and assessed for GDPR compliance. ### What does support look like? **Chat** — Support runs through chat during business hours (CET), with a median first response of under two hours. There is no phone line, and the platform is monitored around the clock. ### Can costs be kept under control? **Yes** — Billing is component based and post-paid, so an account is charged only for resources actually used. Autoscaling can be turned off and a fixed plan picked to cap spending. ### Can custom contracts or SLAs be negotiated? **No** — Terms, DPA and SLA are standardized and identical for every customer. There is no custom-terms negotiation — that standardization is part of what keeps the price low. ### Is fortrabbit ISO 27001 or SOC 2 certified? **No** — fortrabbit holds no own certification; the AWS infrastructure underneath is ISO 27001 certified. SOC audits are not offered. Common questionnaire items are answered openly on the compliance page. --- - [Trust](/trust) - [Cost breakdown](/us/cost-breakdown) - [About us](/us) # For the client Source: https://www.fortrabbit.com/solutions/client Published: 2026-03-15 Updated: 2026-08-23 Reviewed: 2026-07-20 > What fortrabbit hosting means for a business owner — plain answers on billing, ownership, changing developers, support and cancellation. This page exists for a specific moment: a web developer or agency has recommended fortrabbit for a website, and the person who owns that website — a business owner, not a developer — wants to know what they are agreeing to. Or a finished project is about to change hands, and its owner is about to receive the hosting along with it. No technical knowledge is required here. We are the hosting company: we run the computers the website lives on and keep them working, and have done so since 2012. The developer builds and maintains the website itself. This page explains where the line between those two jobs runs, and what it means for the business. ## What the money pays for Hosting is the service that keeps a website reachable on the internet: space on servers, the technology that runs the site, and people watching over both around the clock. The monthly amount is made of parts the developer picks to fit the website — computing power, a database, file storage, and so on. A small website books small parts and costs accordingly; the smallest possible setup starts at €2.50 per month. Current numbers and examples live on the [pricing page](/pricing). Two properties of the billing matter more than the amounts. First, it is post-paid: the invoice arrives after a month of service and covers what was actually used, counted by the day — never a year in advance. Second, the price does not drift on its own: the developer either books a fixed plan, in which case the amount is fixed and a warning email goes out before a limit is reached, or allows automatic scaling up to an agreed cap, in which case a busy month can cost more than a quiet one — within that cap, itemized on the invoice. ## Who owns what On the hosting side, ownership follows the money. Every hosted website belongs to a payment method — a billing profile with a name, an invoice address, and a card or bank account behind it. Whoever controls that billing profile owns the hosting: the invoices carry their name, they decide who may work on the site, and they can cancel. The developer's ability to work on the website is a separate matter entirely — access is granted to a person, for a specific website, and can be given or taken away at any time without the website noticing. That separation makes two clean arrangements possible. Either the developer owns the hosting, pays us, and puts hosting on their own invoice to the client — the business owner then never needs to see any of this. Or the business owns the hosting through its own billing profile, pays us directly, and grants the developer the access needed for maintenance. Both are common, neither is better, and switching from one to the other later is a [short administrative act](/benefits/hand-over) — the website itself does not move and stays online throughout. ## If the developer moves on Developers retire, change careers, get too busy, or the relationship ends badly. What matters then is who owns the hosting. When the business owns it, the answer is short: the old developer's access is switched off, a new developer's access is switched on, and the website keeps running untouched — there is nothing to hand back and nothing the old developer can withhold. When the developer owns it, ownership is transferred first — the handover described above — and because billing is counted by the day, even a mid-month transfer means nobody pays twice for the same period. One honest limit: we can transfer the hosting cleanly, but not the knowledge in the departing developer's head. A new developer still has to get to know the website itself. That goes better when the question of ownership is settled before it becomes urgent. ## Day to day Owning the hosting does not create a daily duty. The owner login is administrative: see and download invoices, update the card on file, change who has access. Checking it when an invoice raises a question is a normal amount of use. The technical work — updates, changes, fixes — remains the developer's, and none of it requires the owner's involvement. The one real obligation is keeping the email address on the account current, because that is where invoices and any billing problems arrive. ## When the site is down The 9 am question: the website is not loading — who gets the call? The developer, first. Most downtime we see is caused by something in the website itself — a change, an update, an exhausted resource — which is exactly the part the developer knows and we deliberately stay out of. Whether the problem is on our side instead can be checked without any login on the public [status page](https://fortrabbit.betteruptime.com). Our support covers the hosting service and billing, not the inner workings of the website. It runs as a chat during business hours (CET); the median first response is under two hours, and there is no phone line. The platform itself is monitored around the clock on our side, backed by a [99.5% uptime commitment](/legal/contract/service-level-agreement). For a technical incident, the most effective setup is the developer talking to our support directly — we can rarely help a worried owner through a conversation that has to be technical, and we say so openly in our [guidance for exactly this situation](/contact/website-down). ## Stopping, on purpose or by accident Cancellation happens in the dashboard, takes effect immediately, and costs nothing extra: the final invoice covers the days used, and no contract term or notice period stands in the way. Nothing about the arrangement continues out of inertia. A missed payment is handled with patience. A failed charge triggers an email and automatic retries over the following weeks; websites are only deleted after several unpaid invoices with no response, and a human reviews each case before that happens. Deleted websites cannot be recovered, so the one thing that protects a business here is reading and answering those emails. The full policy is public in the [late payments article](https://docs.fortrabbit.com/platform/billing/late-payments). And none of this is a trap. Websites here are built on standard, open technology, so a developer can take a complete copy of the site and its data at any time and set it up with another provider. We would rather be chosen than needed. ## Who is behind this A business that depends on its website is also making a bet on the hosting company still existing in ten years. This service has been operated by the same small, independent company from Berlin since 2012 — no investors to satisfy, no acquisition story, and we publish [how the money is spent](/us/cost-breakdown). Being a small business ourselves, we take particular care of the many business websites hosted here. Questions before agreeing to anything are welcome — from the business owner or from the developer on their behalf. ## FAQ ### Do I need technical knowledge to own the hosting? **No** — The owner login covers invoices, payment details and access — administrative tasks only. The developer keeps doing the technical work. ### What happens if I change web developers? **No problem** — Ownership stays with the business. Access for the old developer is revoked, the new developer is granted access, and the website stays online untouched. ### Who do I contact when something is wrong with the website? **It depends** — The developer is the first contact for the website itself. For hosting and billing questions, our support answers directly, and a public status page shows platform-wide issues. ### Can the hosting be cancelled at any time? **Yes** — Cancellation runs through the dashboard and takes effect immediately. There is no contract term, no notice period and no cancellation fee. ### How is the hosting billed? **Monthly** — Post-paid: the invoice arrives after a month of service and covers what the website actually used, counted by the day. There is no annual prepayment. ### What happens when a payment fails? **Emails first** — A failed charge triggers an email and automatic retries. Websites are only deleted after several unpaid invoices with no response, and a human reviews each case before that step. ### Can the website be moved to another provider? **Yes** — The website is built on standard, open technology. A developer can take a full copy of the code and data and set it up elsewhere at any time. --- - [Hand over](/benefits/hand-over) - [Website down](/contact/website-down) - [About us](/us) # Trust Source: https://www.fortrabbit.com/trust Published: 2026-06-13 Reviewed: 2026-06-14 ## FAQ ### Is fortrabbit GDPR compliant? **Yes** — The data processing agreement is part of the terms of service and applies automatically — there is nothing separate to sign. Sub-processors are documented and assessed for GDPR compliance. ### Where is the data stored? **It depends** — Each app runs in the region chosen at creation. The EU region is in Ireland; a US region is also available. Account and billing data is stored in Ireland. Some data is handled by sub-processors, several of them US companies — the full list is public. ### Is this a sovereign cloud? **No** — The infrastructure runs on AWS, a US-owned provider, and several sub-processors are US companies, so the US CLOUD Act can apply. What fortrabbit offers is a German contracting party, GDPR terms by default, an EU region for the app, and transparency about the rest. ### Is the platform monitored? **Yes** — The platform is run by people, not left to autopilot — patched, monitored and staffed on call around the clock. Securing the infrastructure and the stack is part of the service; securing the application on top stays with its developer. ### Can the service be cancelled at any time? **Yes** — Cancellation runs through the dashboard and takes effect immediately. There is no lock-in and no long-term contract. # CMS hosting Source: https://www.fortrabbit.com/use-cases/cms-hosting Published: 2026-07-20 Updated: 2026-08-23 Reviewed: 2026-07-27 > CMS hosting for editor-driven websites: flat-file like Kirby and Statamic, or database-driven like WordPress and Craft. Caching, backups. **In today's web, everybody is headless. But remember the basics.** A CMS that renders its own pages: editors publish, visitors read, and the HTML arrives finished. It's stupid simple, and it's what PHP was built for. ## CMS flavors **Flatfile** CMSes like Kirby and Statamic keep entries as text files in folders; **Database-driven** ones like WordPress, Craft CMS and TYPO3 keep them in MySQL. That's the LAMP stack. Both are supported by fortrabbit. ### Flatfile A flatfile site runs on the PHP and storage components alone. The content folder is runtime data: editors change it on the server, so it belongs in persistent storage rather than the deploy package — the deploy sync only replaces what the package contains and leaves everything else in place. Teams that version content in git instead route edits through deploys; both setups work, but mixing them silently overwrites one side. ### Database-driven A database-driven site adds the MySQL component for entries and settings, while uploads still land in storage. The backup component snapshots both together, so a restore point always holds a matching database and media library. ## Classic or headless Every CMS here can also run headless. Craft and Statamic ship GraphQL and REST layers, Drupal carries JSON:API in core, and WordPress and TYPO3 serve content over an API too. The same PHP app either renders its own pages or answers an API request — the components underneath stay the same. Classic rendering is the default, and the simpler path: one deploy, finished HTML, nothing between the editor and the visitor. Headless splits the site into a content back end and a separate front end — a different shape, with its own reasons and trade-offs. For the decoupled setup — where the back end runs and how the front end connects — see [Headless CMS hosting](/use-cases/headless-cms-hosting). ## Why fortrabbit? fortrabbit has backed old, boring tech like PHP and MySQL since back when it was still cool — and still runs it as the main event, not a legacy checkbox. Push to deploy, keep uploads in persistent storage, and let the page cache carry the readers. ## FAQ ### Is a database required? **Not for flatfile** — Kirby and Statamic store content as files, so an environment runs on the PHP and storage components alone — no MySQL component to book or maintain. WordPress, Craft and TYPO3 expect MySQL; the component is added per environment and billed by the day like everything else. ### Does a content site need a CDN in front of it? **Usually not** — A site with a working page cache and an audience in one region is served fine from the environment itself. A CDN starts paying off when the audience spans continents or large media files dominate the response weight — it is an addition, not a prerequisite. ### Where do editor uploads go? **Persistent storage** — The storage component is a persistent file system. Deploys replace the code directory; runtime data like uploads stays — so a media library survives every release without an external bucket. With autoscaling enabled, larger and smaller storage plans are booked automatically based on measured usage. ### Do scheduled posts publish on time? **Via cron job** — A well-cached site delivers few requests to PHP, so publish-on-visit schedulers like WP-Cron drift. The jobs component runs real cron jobs in dedicated back-end PHP processes, isolated from the web front-end. ### Who upgrades the CMS? **The developer does** — Responsibilities split cleanly: we run the platform, and everything installed on it belongs to whoever deploys it. No CMS version, plugin or Composer dependency is ever touched from our side — an unannounced change to a running site would be worse than an outdated one. An upgrade is a Composer change plus migrations, shipped with a git push like any other release. Trying it on a second environment with a copy of the database first is the usual approach, and components are billed by the day, so that costs days rather than a month. ### Is site migration handled by fortrabbit? **No** — Migration is not offered as a service — users stay in control of their hosting. Moving a site means deploying the code base with git push, importing the database, and copying the media library into persistent storage over SFTP or rsync. The docs cover each step, and support answers questions about the platform. --- - [Backups](/features/backups) - [Developer support](/benefits/get-support) - [Agent ready](/workflows/agentic-engineering) # Side project hosting Source: https://www.fortrabbit.com/use-cases/side-project-hosting Published: 2026-07-20 Updated: 2026-08-23 Reviewed: 2026-07-27 > Hosting for the Saturday idea that should be on a real URL by Sunday. A one-week free trial, billing by the day, nothing left behind. **A hobby project should cost hobby money.** An idea on a Saturday that should be on a real URL by Sunday evening. It might become something. It probably won't. Both outcomes are fine, and the hosting shouldn't punish either. ## From repo to URL in an evening What a hack needs on day one is small: PHP, a database, and an address. Each new app starts as a free trial — seven days, no credit card — and answers on a test domain with TLS already in place, so there is no domain to buy and no certificate to wire up before anyone can look at it. Connect the GitHub repo and push; the deploy service runs Composer and the app is live. Software templates pre-configure the build settings per framework, so the first push works without tuning anything first. ## Kill it or grow it Plenty of these go nowhere, and the platform is built for that. A trial app with no payment method deletes itself when the week ends, and a paid app stops billing the day it's deleted — nothing survives except the Git repo. No subscription quietly running in the background, no server to remember to cancel. The few that grow scale a component at a time, on the same host, without a migration. The downside is cheap and the upside doesn't require moving. ## Why fortrabbit? Because this is where fortrabbit came from. Hosting ran for years as a side gig next to agency work, on servers we bought ourselves, long before it was a company — nobody here needs convincing that most weekend ideas die and the odd one changes everything. Push to deploy on a free trial, share the link on Sunday, and delete it on Monday for the price of a weekend. When it doesn't die, it stays where it is and grows a component at a time. ## FAQ ### How long does the first deploy take? **Minutes** — Create an app in the dashboard, connect the repo through the fortrabbit GitHub app, push. The deploy service runs Composer and the app answers on its test domain over HTTPS. Software templates pre-configure the build settings, so nothing has to be tuned before that first push works. ### What does a side project cost? **Cents per day** — Only PHP, storage, and traffic are required components; MySQL gets booked when the project needs it. Everything starts on the smallest plan, a day costs 1/30th of the monthly price, and billing is postpaid. ### What happens when the project is abandoned? **Nothing** — A trial app without a payment method deletes itself when the week ends — no forgotten subscription billing away in the background. With a payment method attached, deleting the app stops the billing that same day. Either way the experiment leaves nothing behind except the Git repo. ### Is a custom domain needed on day one? **No** — Every environment comes with a test domain like en-34fdsa.frbit.app, TLS certificate pre-installed, always served over HTTPS. That's enough to share a link, collect a first reaction, and decide whether the idea deserves a real domain later. ### What if the hack actually takes off? **Scale a component** — Components scale individually, so a project that gets attention usually needs a bigger PHP plan and nothing else. Plan changes take immediate effect and are prorated by the day — no migration, no re-platforming, the same app grows. --- - [Free trial](/benefits/try-free) - [Test domain](/features/test-domain) - [Agent ready](/workflows/agentic-engineering) # Dashboard hosting Source: https://www.fortrabbit.com/use-cases/dashboard-hosting Published: 2026-07-22 Updated: 2026-08-23 Reviewed: 2026-07-27 > Host a PHP dashboard app — analytics panels and data visualizations — with the heavy aggregation precomputed in the jobs component so the charts load fast. **Ten people watching. Fifty million rows behind them.** A PHP application whose whole job is to show numbers: an analytics panel, a reporting tool, a metrics wall on an office screen. The charts are the visible part, and the cheap part. The work sits behind them, in the queries that turn raw rows into the figure on display. ## The aggregation runs before the request The slow query is the one that reads a whole table to produce a single average. Running it on every page load ties the dashboard's speed to the size of the data, which only moves one way. Cron jobs in the jobs component do that reading on a schedule and write the results into summary tables. The panel reads a small, ready-made row instead, and the expensive part already happened where nobody was waiting. A rollup over a year of events can take minutes in a worker without a browser tab spinning. ## "Real time" is a poll, not a push Persistent connections aren't available here, and it's worth being plain about it: nothing on the platform pushes an update to a panel that's already open. WebSockets and live-streaming charts are out. What works is polling — the panel asks again every few seconds — or a refresh on the precomputed data as each rollup lands. For a dashboard that trails reality by design, the difference is hard to see. ## The data outgrows the traffic Ten people might watch a dashboard that sits on tens of millions of rows. Counted by visitors it looks idle. The database says otherwise. Load-based reasoning gives the wrong answer, the same as it does for an [internal tool](/use-cases/internal-tool-hosting). Components are booked one at a time, so MySQL grows on its own — more storage and memory for the data — while the PHP component stays small, each billed pro-rated by the day. ## Why fortrabbit? A dashboard's cost sits in the database rather than the page, and the components here are booked separately. MySQL is managed as a first-class part of the platform — PHP and MySQL have been the main product at fortrabbit from the start. Precompute in the jobs component, scale the database for the data while PHP stays small, and pay per day for what each component uses. ## FAQ ### Can the panels update in real time? **Near real time, by polling** — Persistent connections are not available on the platform, so nothing pushes an update to a panel that is already open — anything built on WebSockets is out. Panels refresh by polling on an interval, or by reloading the precomputed data as each rollup lands. For a metrics view, a few seconds of lag reads as live. ### Where should the heavy aggregation run? **In the jobs component** — Rolling up millions of rows on every page load ties the dashboard's speed to the size of the data. Cron jobs in the jobs component do that reading on a schedule and write the results into summary tables. The panel then reads a small, ready-made row, and the expensive query already ran where nobody was waiting. ### What happens when the dataset outgrows the traffic? **Scale MySQL on its own** — A dashboard's data usually grows faster than the number of people watching it. The database component is booked and scaled independently of PHP and billed pro-rated by the day, so storage and memory grow without paying for web capacity that stays idle. ### Does the charting need a special runtime? **No** — Charts render client-side with the usual libraries — Chart.js, ECharts, ApexCharts — or as server-side SVG from PHP. It is an ordinary PHP application deployed with git push; nothing on the platform is specific to visualization. ### Can it read from other systems? **Yes** — Outbound calls to a data warehouse, an analytics API, or another database work. Each environment has a fixed outgoing IP the other side can allowlist, and non-standard ports open per environment from the fortrabbit dashboard. Scheduled imports run in the jobs component. --- - [Jobs and workers](/features/jobs) - [MySQL](/features/mysql) - [Agent ready](/workflows/agentic-engineering) # Web app hosting Source: https://www.fortrabbit.com/use-cases/web-app-hosting Published: 2026-07-20 Updated: 2026-08-23 Reviewed: 2026-07-27 > Host a PHP web app on a managed PaaS — git-push deploys, background workers for billing and scheduled work, and components that scale one at a time as you grow. **Ship the app, not the server.** Shipping a product is hard enough without becoming a sysadmin on the side. fortrabbit runs the platform so the work stays on the application, which is the business. ## No DevOps hire required A small team cannot spare a person to patch servers, wire up a deploy pipeline, and chase certificates. None of that exists to do here: connect a Git repository, push, and the app is live over HTTPS. The operating system, the web server, scaling, and TLS are handled. What remains is the code and the database. ## The chores that are not requests run in workers Trial expiry, usage metering, invoice runs, imports, dunning mail — the machinery behind a web app happens on a schedule, and none of it belongs inside a web request. The jobs component runs real cron jobs and long-running queue workers next to the web processes, on the same code and the same environment. Laravel Cashier and Symfony Messenger drop straight in, and a billing run that takes 20 minutes takes 20 minutes in a worker, with nothing timing out. ## Pay as it grows, not per seat Cost follows load and data, not the number of accounts — the first customers run for cents a day. Components are booked individually and billed pro-rated by the day, so PHP can scale ahead of the database, or the reverse, without jumping to the next bundled tier. Customer 500 usually needs more PHP processes and nothing else: scale that one component and keep going, same app, same host. ## Why fortrabbit? Because we run one. fortrabbit is a bootstrapped subscription business that has been running on AWS since 2012 with no VC money behind it — roughly the position most founders reading this are in. Spend the runway on the product: start on a free trial, deploy with a push. The platform covers what the DevOps hire would. ## FAQ ### Is a DevOps person needed to run it? **No** — fortrabbit is managed: a git push deploys, TLS is issued and renewed automatically, and the operating system, web server, and scaling are handled. There is no pipeline to build and no server to patch — the work stays on the application. ### What runs billing, trials, and metering? **Background workers** — The jobs component runs cron jobs and long-running queue workers beside the web processes, on the same code and environment. Laravel Cashier and Symfony Messenger run there unchanged, so invoice runs, trial expiry, and dunning mail happen on schedule without holding up a request. ### What does it cost with a handful of customers? **Cents a day** — Every app starts on a seven-day free trial, no card required. After that, cost follows load and data size rather than account count, billed pro-rated by the day — an early product with a few customers runs on the smallest components for cents a day. ### Does it scale when the product takes off? **Per component** — Components scale one at a time and take effect immediately, pro-rated by the day. Customer growth usually means more PHP processes, not a bigger everything — scale that one component while the database stays put, on the same app and host. ### Are realtime dashboards or push updates supported? **No** — The platform has no persistent connections, so anything built on WebSockets is out. Live counters, notifications, and activity feeds work with polling on a sensible interval, or with mail sent from a worker. --- - [Background jobs](/features/jobs) - [Scale on demand](/benefits/scale-on-demand) - [Agent ready](/workflows/agentic-engineering) # API backend hosting Source: https://www.fortrabbit.com/use-cases/api-hosting Published: 2026-07-20 Updated: 2026-08-23 Reviewed: 2026-07-27 > Host a PHP API backend — Laravel, Symfony or Tempest answering JSON. Git-push deploys, queue workers and cron jobs beside the web layer. **The clients ship on their own schedule. The backend can't wait for them.** A PHP service that answers JSON, consumed by clients it doesn't control and can't deploy. No templates, no session cookies — only routes that take a request and return data. Deploys go by git push: the build runs Composer in a separate deploy container, and only the finished package is synced in. Migrations and console commands run over SSH. ## Work that isn't a response Sending mail, generating exports, and calling third parties that time out have no business inside a request. The jobs component runs workers and cron jobs in a container isolated from the web layer, sharing the code base, database, and env vars — a webhook handler that writes a row and returns immediately survives a spike that a synchronous one won't. Jobs scale by memory and job count, separately from PHP. Persistent connections aren't supported, so APIs that need to push do it by polling or by calling webhooks back out. ## Old versions don't leave on request A mobile app in the wild pins the contract for as long as people postpone updates, and no deployment on this side changes that. Route prefixes and header negotiation cover the small breaks. For a hard one, a major version runs as its own environment: each environment tracks its own Git branch and books its own components, so v1 sits frozen on a small PHP plan while v2 settles beside it. The same mechanism does duty before the break. A staging environment runs the next contract against a copy of the data, on a test domain with HTTPS from the first deploy — client developers integrate against a real URL instead of a mock. ## Why fortrabbit? Deploys, SSH, cron jobs, and queue workers are part of the platform here, not add-ons sold on top of it. fortrabbit is still run by the people who built it. Push to deploy, keep the slow work in the jobs component, and scale PHP and workers apart. The API stays quick while the front ends multiply across app stores, CDNs, and hosts nobody here has to manage. ## FAQ ### Can one API serve a website, a mobile app and a SPA at once? **Yes** — That is the usual arrangement. The backend exposes one set of endpoints and stays unaware of who calls them. Clients release on their own schedule — an app store review does not require a deployment here, and a deployment here does not wait for one. ### Are queue workers and scheduled jobs supported? **Yes** — The jobs component runs worker and cron jobs in a separate runtime container, with access to the same file system, database, and env vars as the web layer. Laravel's database queue driver works with the MySQL component out of the box, and php artisan schedule:run fires from a cron job every minute. Each deployment restarts running workers, so they always execute the latest code. ### Does the platform support WebSockets for real-time endpoints? **No** — Persistent connections are not supported on the platform. APIs that need push semantics can poll, send webhooks out to the client, or delegate that one channel to an external service dedicated to it. ### How is API versioning handled? **By routing** — Route prefixes and header negotiation are application concerns. For a hard break, run each major version as its own environment — every environment maps to its own Git branch and books its own components, so v1 stays frozen while v2 settles. ### What does an API backend cost to run? **Per component** — An environment books exactly the components it needs — PHP, MySQL, jobs — and billing is pro-rated, post-paid, on a daily cycle. A small API with a database and one worker starts small and grows one component at a time; there is no jump to a bundled tier. New apps start as a free trial: seven days, no credit card. --- - [Jobs and workers](/features/jobs) - [Staging environments](/features/staging-environments) - [Agent ready](/workflows/agentic-engineering) # E-commerce hosting Source: https://www.fortrabbit.com/use-cases/e-commerce-hosting Published: 2026-07-20 Updated: 2026-08-23 Reviewed: 2026-07-27 > Host a PHP online store — Shopware, Lunar or WooCommerce. Traffic spikes, persistent media storage, background order processing, safe deploys. **Checkout is the least forgiving code path in PHP.** It must never lose a write, and a deployment must never take the shop down with it. Shopware, Lunar on Laravel, and WooCommerce all run on PHP because the ecosystem around payments, tax, and shipping is deeper in this language than in the alternatives. ## Peaks are events, not growth Store traffic answers to campaigns rather than to a trend line. A newsletter goes out, a piece gets shared, or it's the last Friday in November, and the peak is 10 or 20 times the median for a few hours. Scaling the PHP component up for a campaign and back down afterwards is a normal operation — the good part is that the date is known weeks in advance. ## Orders finish after the request does Payment capture, stock sync, invoice generation, and feeds to an ERP or a marketplace belong in the jobs component rather than in a request handler. Worker jobs drain the queue, cron jobs run the scheduled syncs, and both are restarted after every deployment so they always run the latest code. A store built that way absorbs a burst in the queue and works through it afterwards. Card data belongs with the payment provider, not on the shop's own host. What the store does keep — addresses, order history, e-mail — lives in MySQL with the backup component behind it. ## Why fortrabbit? Because a shop cannot afford a host that struggles with a campaign spike or a deploy, and even less one that reinvents itself every year. fortrabbit has run PHP and MySQL on AWS since 2012, bootstrapped, with no habit of moving the ground under its customers. Components scale up for the peak and back down after, orders finish in workers instead of in the checkout request, and every restore point holds a matching database and media set. No ops team needed to watch the graphs. ## FAQ ### Can the platform handle a Black Friday spike? **With planning** — Campaign peaks are predictable, which is the useful part. Each component scales on its own: the PHP plan is raised in the dashboard for the days that need it and lowered afterwards, while traffic, storage, and MySQL can autoscale with usage. Each day is billed at 1/30th of the monthly rate, so a week of extra capacity costs a week, not a month. ### Where do product images and customer uploads go? **Persistent storage** — On the web storage of the environment, which is persistent. Product media, generated thumbnails, and invoice PDFs written at runtime stay where they are — the default merge deployment strategy syncs new code in without deleting runtime files. Storage autoscales as the catalog grows, and the backup component snapshots it daily. No S3 bucket required. ### Where does card data live in a hosted shop? **With the payment provider** — Not on the shop's own host. Modern checkouts hand the card off to Stripe, Mollie, Adyen, or PayPal through a hosted field or a redirect, so the store only ever holds order records and tokens. A configuration that puts card numbers on the application host moves the compliance burden onto the merchant, which is the wrong place for it. ### Can a live store be deployed to without an outage? **Mostly** — A Git push runs the build — Composer, asset bundling — in a separate deploy container, not on the live host, and only the finished package is synced into the web space. The risk that remains is the application's own: database migrations in the post-deploy commands and cache warm-up. Both are worth rehearsing on a staging environment before they meet a live checkout. ### Can the storefront show live stock or order updates? **No** — Persistent connections are not supported, so anything that pushes updates into an open page is out of scope. Stock levels refresh on page load or by polling on a sensible interval, which is how most storefronts work in any case. --- - [Backups](/features/backups) - [Scale on demand](/benefits/scale-on-demand) - [Jobs](/features/jobs) # Headless CMS hosting Source: https://www.fortrabbit.com/use-cases/headless-cms-hosting Published: 2026-07-20 Updated: 2026-08-23 Reviewed: 2026-07-27 > Host the back end of a decoupled CMS setup — Craft, Statamic or Drupal serving content over an API, with the front end deployed wherever it fits. **The front end will be rewritten. The content won't.** A decoupled setup splits one site into two deployable things, joined by an API and nothing else. This page is about the half that owns the content: a PHP application with a database, an asset store, and an admin interface. Craft and Statamic ship GraphQL and REST layers for exactly this; Drupal carries JSON:API in core. For the undecoupled version — one engine rendering its own pages — see [CMS hosting](/use-cases/cms-hosting). ## Build traffic, not visitor traffic A decoupled CMS gets very little traffic. Editors log in during working hours, and the front end queries the API — continuously if it renders on request, or in bursts if it pre-renders at build time. That build is the surprising part. A full pre-render walks every entry, so one build can fire more API requests in a few minutes than the rest of the day combined. Sizing for the average misses it entirely; what absorbs the burst is the CMS response cache, since most entries didn't change between builds. ## The back end is the half that lasts Front ends get rewritten every couple of years. The content model, the editorial workflow, and a decade of uploaded assets are expensive to move and cheap to keep. The CMS is better hosted somewhere that does not assume it also serves the public site. The CMS deploys like any PHP app here: git push, Composer in the build, then the deploy package syncs in without deleting the uploads already there. fortrabbit hosts the PHP half; a pre-rendered JavaScript front end is a different workload and belongs on a [host built for static output](/use-cases/static-site-hosting). ## Why fortrabbit? PHP and MySQL as the main product, not as a compatibility mode. That is all fortrabbit has ever done, since before headless was a word for it. Managed, PHP-first, bootstrapped, and unlikely to discover a more fashionable core business. Deploy the CMS with a push, let the response cache absorb the build bursts, and keep a decade of assets in persistent storage while the front end moves to whatever suits it this year. ## FAQ ### Is a headless CMS product offered here? **No** — fortrabbit hosts the CMS that a team installs and controls — Craft, Statamic, Drupal, and other PHP applications. It is not an alternative to Contentful, Strapi, or Sanity. The content model, the plugins, and the upgrade schedule stay in the team's hands. ### Can the front end be hosted here too? **Sometimes** — A PHP front end can run as a second app in the same account, sharing billing and access. A pre-rendered JavaScript front end is a different kind of workload and is usually deployed to a platform built for static output. ### How do editors preview unpublished content? **Through the CMS** — Preview is handled by the CMS itself. Craft and Statamic both render a preview target against draft content, and that target can be the decoupled front end as long as it can be reached over HTTP and accepts a preview token. ### What happens to caching when an editor publishes? **Invalidation** — The CMS fires an event on save. Whether that clears a cache key, purges a CDN path, or calls the front end's build hook is application logic. The CMS keeps its own cache on the file system or in MySQL; outgoing HTTPS requests handle the purge and the hook. ### Where do images and uploads live? **In persistent storage** — Uploads go to the app's persistent storage — a real file system that survives deploys, because the default merge strategy overwrites what the deploy package contains and leaves everything else untouched. The asset filesystem abstractions in Craft, Statamic, and Drupal can also point at an external object store, but none is required. --- - [Build commands](/features/build-commands) - [Install guides](/guides) - [Agent ready](/workflows/agentic-engineering) # Portfolio hosting Source: https://www.fortrabbit.com/use-cases/portfolio-hosting Published: 2026-07-20 Updated: 2026-08-23 Reviewed: 2026-07-27 > Host a portfolio site: media-heavy, low traffic, long-lived. For designers and photographers showing work, or agencies building it for them. **One visitor matters more than the other thousand: the one deciding whether to hire.** A portfolio shows the work and wins the next job. Sometimes it belongs to the person who made the work — a photographer, illustrator, audio engineer, developer. Just as often a freelancer or agency builds it for a creative client and keeps it in the same account as the rest of their work. Either way the shape is the same: a body of work a stranger can take in quickly, and a way to make contact. ## Very little logic, a great deal of media PHP renders a handful of templates and stops; the weight is in the media. Every environment books storage as a required component — a persistent file system with SSH and SFTP access, so uploads survive deploys instead of living inside a build. Media committed to the repository ships with each git push, which suits a site that changes twice a year. ## Quiet for months, then vertical for two days A portfolio gets a trickle until a project is picked up somewhere. Almost all of that traffic is anonymous reads, so the CMS's page cache absorbs most of it before PHP does real work — and the PHP component can be scaled up for a few days and back down, each day billed at 1/30th of the monthly rate. Months pass between updates, which is its own risk: the software goes unpatched as long as nobody touches it. A flat-file CMS keeps content in the repository, so there is no database component to book and the whole site restores from a Git clone plus one rsync of the uploads. ## Why fortrabbit? Because we ran a web agency before we ran a hosting company, and the portfolio was always the same job: no budget, no traffic, and more riding on it than anything else in the account. A flat-file build that ships with the repository, storage that survives every deploy, and per-day billing that stays near the floor between bursts. When it is client work, ownership [hands over](/benefits/hand-over) without the site changing address — an administrative act, not a migration. ## FAQ ### Does a portfolio need a CMS at all? **Not always** — Plenty of good portfolios are a handful of templates and a folder of images with no database anywhere. A flat-file CMS like Kirby sits in between: content lives in files, there is no database component to book, and the site is reproducible from a Git clone. ### Where do large images, audio, and video files belong? **On web storage** — Uploads land on the environment's storage component — a persistent file system, reachable over SSH and SFTP, that deploys don't overwrite. Media committed to the repository ships with each git push. Long video is still better served from a dedicated video host and embedded. ### What happens when a project gets picked up and traffic spikes? **Cache, then scale** — A portfolio is almost entirely anonymous reads, so the CMS's page cache and sensible Cache-Control headers absorb most of a spike before PHP is involved. For the rest, the PHP component scales up in the dashboard and back down days later — each day billed at 1/30th of the monthly rate. ### Is this overkill for a site that changes twice a year? **Only with PHP** — A portfolio with no PHP in it at all is well served by a static host. fortrabbit fits when the site runs a CMS, a contact form, or an image pipeline — and when the same account already holds client work next to it. ### What does a quiet year cost? **The smallest plans** — Components stay booked and billed whether or not anyone visits. For a small portfolio that means the three required components — PHP, storage, and traffic — on their smallest plans, post-paid, with no minimum term to renegotiate when it gets busy again. --- - [Free certificates](/features/free-certificates) - [Relax](/benefits/relax) - [Agent ready](/workflows/agentic-engineering) # Internal tool hosting Source: https://www.fortrabbit.com/use-cases/internal-tool-hosting Published: 2026-07-20 Updated: 2026-07-27 Reviewed: 2026-07-27 > Host the internal PHP application only staff uses — admin panels, intranets, stock and reporting tools. Low traffic, high consequence, long service life. **The least glamorous PHP in the building, and the most load-bearing.** The application only a company's own staff uses: an admin panel, an intranet, a stock or logistics tool. PHP holds an enormous share of these, written quickly, years ago, by whoever was available. ## Low traffic, high consequence 20 concurrent users at peak, nothing on weekends. By every metric a hosting dashboard reports, the application looks idle. When it stops, invoices aren't raised and shipments aren't booked, and the manual fallback was forgotten years ago. Load-based reasoning gives the wrong answer here. The PHP component and the database run through the working day whether anyone logs in or not, and that, plus backups, is the bill. ## Wired into the other systems An internal tool is rarely alone. It reads orders from the ERP, posts labels to the warehouse, mails a report before the shift starts. Each environment has one fixed outgoing IP, so the firewall on the other side has a single address to allowlist. Non-standard ports open per environment from the dashboard, and scheduled imports and exports run as cron jobs in the jobs component. Persistent connections and WebSockets are not supported. ## Old code, current runtime Age in the application is fine. A CakePHP or CodeIgniter code base nobody has touched in years deploys like any other — git push, Composer, done. Age in the runtime is the limit: the platform starts at PHP 8.2, and an application pinned below that needs work first. That work happens in a second environment. Same code, newer PHP, proven there before anyone in the company sees it. ## Why fortrabbit? Because boring is the entire specification, and boring on purpose is what fortrabbit has been doing for over a decade — managed PHP, bootstrapped, still run by the people who built it. A current runtime nobody in-house has to patch, daily backups behind data that exists nowhere else, and support answered by the operators of the platform rather than a ticket desk. That last one matters more than it should, because the developer who wrote the tool usually left years ago. ## FAQ ### Can access be restricted to the office network? **Coarsely, yes** — There is no VPN or private networking — an internal tool is reachable over the public internet like any other app. Two coarse gates exist: the password protection setting puts HTTP basic auth in front of the whole environment, and .htaccess rules can limit access to known office IPs. Both apply to the environment as a whole; anything per-user runs through the application's own login. ### Does an older code base still deploy? **Usually yes** — Age in the application is fine; age in the runtime is not. A CodeIgniter or CakePHP code base from years back runs happily as long as it works on PHP 8.2 or newer — that is where the platform's version range starts. Applications pinned to an end-of-life PHP release are not a good fit. ### Is a low-traffic app cheaper to run? **Somewhat** — Traffic is rarely the cost driver here. What is paid for is existence — a PHP component and a database that must be available during working hours regardless of how few requests arrive. Components are booked individually and billed pro-rated by the day. ### Can the tool talk to other internal systems? **Yes** — Outbound calls to an ERP, a warehouse API or a mail server work; non-standard ports are closed by default and get opened per environment in the dashboard. Each environment has a fixed outgoing IP the other system's firewall can allowlist. The jobs component runs the scheduled imports and exports. Persistent connections and WebSockets are not supported. ### How important are backups for an internal tool? **Very** — More than for a public site, because the data is often unique to the company and exists nowhere else. The backups component keeps restorable snapshots, which matters most for applications whose original developer has long since moved on. --- - [Backups](/features/backups) - [Developer support](/benefits/get-support) - [Agent ready](/workflows/agentic-engineering) # Static site hosting Source: https://www.fortrabbit.com/use-cases/static-site-hosting Published: 2026-07-21 Updated: 2026-08-23 Reviewed: 2026-07-27 > Static site hosting alongside PHP apps — upload finished HTML or let build commands run an SSG like Astro, Nuxt or Statamic at deploy time. **Static sites rarely need us. Static sites standing next to PHP apps do.** Finished HTML, CSS, and images — written from scratch or generated from templates and content at build time. Nothing executes per request; the web server hands out files. ## Next to the PHP apps For a static site on its own, hosts built for static output are hard to argue with — free tiers, global CDNs, instant rollbacks. We don't pretend to beat that. The site worth hosting here is the one that isn't alone: an agency running a dozen PHP apps with one static microsite in between, or a project where the marketing pages are static and the application behind them is not. One account, one deploy workflow, one bill. When the static site needs a form or a search box, PHP is already there. ## Generated on deploy, or uploaded as-is A git push triggers the deploy pipeline, and build commands run Composer and Node.js tasks before the result syncs to the web space. That is enough to run a static site generator on every deploy: Statamic's SSG on the PHP side, or JS stacks like Astro, Nuxt, and Eleventy on the Node side. The repository holds source and content; the server only ever sees the output. This very website works that way — a Nuxt app pre-rendered at build time, served as flat files from fortrabbit. ## Nothing to size, little to pay With no code executing per request, the smallest PHP plan is the right one. There is no database component to book, no cache to configure, no memory limit to reason about. Billing is pro-rated, post-paid, by the day, which keeps a site that hardly changes close to the bottom of the invoice. ## Why fortrabbit? What makes this worthwhile is the applications around the static site. fortrabbit is a PHP host that serves files well, not a static platform hoping to grow a runtime one day, and would rather say so than sell the wrong thing. One account, one deploy workflow, one invoice for the microsite and the applications beside it. ## FAQ ### Is fortrabbit the best host for a static site? **Often not** — A standalone static site is usually served cheaper on a platform built for static output, with a CDN in front and a free tier underneath. The case for hosting it here is proximity: when the site lives next to PHP apps in the same account, it shares the deploy workflow, the access setup, and the bill — one provider instead of two. ### How does the HTML get on the server? **git push** — The usual way is a git push: the deploy package is synced to the web space, and build commands can generate the pages on the way. Files can also be uploaded over SFTP, which suits a site that is exported elsewhere and published as-is. ### Can the site be generated at deploy time? **Yes** — Build commands run Composer and Node.js tasks in a separate deploy service on every git push. That covers nuxt generate, an Astro build, Eleventy, or Statamic's static site generator — the source lives in the repository and the finished pages land in the web space. ### Which components does a static site need? **The smallest** — One small PHP component serves the files; there is no database to book, no jobs, and usually no extra storage. Since components are billed pro-rated by the day, a static site is about the cheapest thing that can run on the platform. ### What about forms and search? **Add PHP later** — A static site that outgrows itself doesn't need a new host. A contact endpoint or a search route can run as PHP next to the generated pages, or as a second app in the same account — the deploy workflow stays the same. --- - [Build commands](/features/build-commands) - [Free certificates](/features/free-certificates) - [Cancel any time](/benefits/cancel-any-time) # Campaign site hosting Source: https://www.fortrabbit.com/use-cases/campaign-site-hosting Published: 2026-07-20 Updated: 2026-08-23 Reviewed: 2026-07-27 > Host a site that exists for six weeks — a launch, a conference, a promotion — with per-day billing, a plan for the traffic spike and a defined ending. **Every campaign site has a launch date. Few have an end date in the billing.** A launch, a conference, an election, a seasonal promotion. The site exists for six weeks and should stop costing money afterwards. The deadline is external and immovable, which is the fact that shapes every other decision. ## The same shape, many occasions Campaign sites arrive under different names, but the brief is always a fixed date, a burst of attention around it, and no reason to keep paying once it has passed. - **Launches** — a product, an album, a book, a film, a rebrand, an open-source project going public. - **Events** — a conference, a festival, a trade fair stand, a hackathon, a program that changes weekly until the day itself. - **Politics and fundraising** — an election, a referendum, a petition, a crowdfunding round, a charity appeal with a closing date. - **Retail and seasonal** — Black Friday, an advent calendar, a pop-up store, a limited edition that sells out and then needs a page saying so. - **Company moments** — an anniversary, a recruiting push, a merger explained on a microsite, an annual report published as a site rather than a PDF. - **Media and teaching** — a data investigation, a documentary companion, a scrollytelling piece, a course cohort, a competition with entry and voting phases. The traffic curve is the same in each case: nothing, then a spike on the announcement, then a long tail that nobody budgets for. ## Built on the test domain, launched on the real one Every environment comes with a test domain like `en-34fdsa.frbit.app`, served over HTTPS from the first deploy. The site is built, reviewed, and signed off there while the campaign is still under embargo — no DNS setup, nothing public to find. On launch day, the real domain is added and gets its TLS certificate automatically, usually minutes after DNS resolves. The announcement spike is handled from the dashboard: each component scales individually, up before the press hit and back down once the curve flattens, with each size billed only for the days it ran. ## Six weeks should cost six weeks Apps are created and destroyed on demand, billing is pro-rated and post-paid with a one-day minimum, and there's no contract to see out. A site that runs for 41 days is billed for 41 days. The common failure is the opposite: the launch passes, the team moves on, and a host keeps billing monthly for two years because deleting it was nobody's job. ## Decide the ending at the start A campaign site ends in one of three ways, and choosing at the start is what makes the ending cheap. It gets archived — crawled to flat HTML and published on a static host, while the app is deleted, since fortrabbit runs PHP applications rather than static output. It gets [handed over](/benefits/hand-over) — ownership and billing move to the client's account while the app stays where it is, nothing redeployed. Or it's destroyed, and billing stops that day. Domains are registered separately and survive all three, which matters because the domain keeps earning long after the campaign. ## Why fortrabbit? Because pay-as-you-go, post-paid, cancel-any-time has been the billing model here from the start, and a site with a deadline is where that shows. Build it on the test domain while the campaign is still under embargo, launch it on the real one, scale for the announcement and back down a week later, then end it deliberately. Six weeks costs six weeks. ## FAQ ### Is there a minimum contract for a short-lived site? **No** — Apps are created and destroyed on demand. Billing is pro-rated and post-paid with a one-day minimum billing period, so a site that runs for 41 days is billed for 41 days. Cancellation takes effect immediately, not at the end of a term. ### How should a campaign be sized for a traffic spike? **Start small, scale up** — Components are booked individually and can be resized while the app runs. The usual approach is to launch on a small PHP plan, watch the first hours, and scale up if the press hit arrives. Because scaling is billed by the day, an oversized week costs a week rather than a month. ### Can a finished campaign be kept online cheaply? **Elsewhere** — fortrabbit hosts PHP applications, not static output. A finished campaign is usually crawled into flat HTML and that snapshot is published on a static host, while the fortrabbit app is deleted. The domain stays registered and points at the snapshot. ### What happens to the domain after the app is deleted? **It survives** — Domain registration is separate from hosting and is unaffected by deleting an app. DNS records can be repointed to wherever the archive lives, or the domain can be redirected to a page on the main site. ### Is a flat-file CMS a good fit here? **Usually yes** — Grav, Kirby, and Statamic keep content in files in the repository, which removes the database from the deployment and makes the whole site reproducible from a Git clone. That matters most at the end, when the site has to be archived or handed on. --- - [Cancel any time](/benefits/cancel-any-time) - [Test domain](/features/test-domain) - [Agent ready](/workflows/agentic-engineering) # Use cases Source: https://www.fortrabbit.com/use-cases Published: 2026-07-20 Reviewed: 2026-07-20 # Hosting for code crafters Source: https://www.fortrabbit.com/workflows/code-crafting Published: 2026-07-24 Updated: 2026-08-23 Reviewed: 2026-07-24 > Hosting for hand-written PHP — plain Git deployment, Composer builds, SSH access and real logs, with no proprietary layer between the code and the runtime. **Some code is still typed on purpose.** A developer opens an editor and builds the application line by line. fortrabbit is AI-ready but not AI-all-over-the-place. Use boring tech. ## Made by people > Build the web you want to see. The dashboard is ~80% hand-written, not assembled from a template and left to drift. Automation handles the tedious parts of hosting: deploys, backups, TLS certificates. It works in the background to serve the person at the keyboard, not to make the decisions for them or eat the data. ## Real people answer Support is staffed by the developers who run the platform, not a queue of scripted replies. A question about a failing deploy or an odd Composer error reaches someone who can read the same logs and knows the stack underneath. No tiered escalation, no bot to get past first. ## Standard stack, standard tools Underneath is an ordinary LAMP stack — Linux, Apache, MySQL, PHP — reached over SSH and deployed with Git and Composer. Nothing proprietary sits between the code and the runtime, so the habits a developer already has carry over unchanged. Where something is specific to fortrabbit, the [platform documentation](/platform) covers it in depth: setup per framework, the reasoning behind the defaults, and the edge cases most hosts leave to guesswork. ## Why fortrabbit? Because the infrastructure was built with the same care, by people who have run PHP in production since before Instagram was a thing. ## FAQ ### Is there a proprietary framework to learn? **No** — The application is a standard PHP project. Deployment runs Composer and the build commands declared in the repository; there is no vendor SDK, no lock-in wrapper, and nothing to import. Moving the code elsewhere means pointing another host at the same Git repository. ### Can the runtime be inspected directly? **Yes, over SSH** — Every environment is reachable over SSH and SFTP with key authentication. Logs from PHP, Apache, and jobs can be tailed live, so a failing request is read at the source rather than guessed at from a dashboard summary. ### How much of the build can be controlled? **All of it** — Build commands run on every deploy — Composer install, asset compilation, migrations, cache warming. They are declared per environment and versioned with the code, so the build that runs in production is the one in the repository. ### Does hand-written code deploy differently? **No** — Every environment maps to a Git branch; pushing it runs Composer through the fortrabbit GitHub app and swaps the release. Hand-written or agent-written, the commit ships the same way — what differs is who authored it. ### What does it cost to run? **Pro-rated by the day** — Every app starts on a seven-day free trial, no card required. After that, only the booked components are billed — PHP, storage, traffic, and MySQL when needed — pro-rated by the day and post-paid, so a plan change or a deleted environment settles the same day rather than the next month. ### Which PHP software is supported? **Anything Composer-based** — Laravel, Symfony, Craft CMS, Statamic, and plain PHP all run the same way: a Composer project deployed with git push. There is no curated list to fit into — if it builds with Composer and speaks PHP, it belongs here. --- - [SSH and SFTP](/features/ssh-sftp) - [Build commands](/features/build-commands) - [GitHub integration](/features/github-integration) - [Platform reference](/platform) # Hosting for agentic engineers Source: https://www.fortrabbit.com/workflows/agentic-engineering Published: 2026-07-20 Updated: 2026-10-10 Reviewed: 2026-08-23 > Hosting for agentic engineering — agent skills, machine-readable docs, per-environment deploy triggers, daily billing for throwaway branch environments. **Your agent writes the code and ships it through fortrabbit.** You describe the intent, it edits the codebase, the tests run, and you review and deploy. What comes out is an ordinary Laravel or Symfony project. What changed is how fast the loop around it turns. ## Agent interfaces The open source [agent skills](/features/agent-skills) install locally and turn platform operations into prompts: `/fortrabbit deploy`, `db down` and `ssh` run deployments, database syncs and remote commands over plain SSH and rsync. Your agent tails the PHP, Apache and job logs the same way, so it quotes the failing line instead of asking you to go look. The [MCP server](/features/mcp-server) hands over the platform objects themselves — apps, environments, deployments, domains, variables. You authorize it in the browser, with no token pasted into a config file. The [public API](/features/public-api) is the same surface over REST for everything that is not an agent. The [CLI](/features/cli) wraps it in one binary for your terminal or a CI job. Run one agent or a fleet; none of these interfaces assume a human is holding them. ## Accessible docs Your agent needs to know how deployment works, or why a build failed. It reads. Documentation wrapped in a JavaScript app behind a search box is close to unusable for that. Plain Markdown at a predictable URL works. Every docs article ships as raw Markdown, plus `llms.txt` and `llms-full.txt` for retrieval — a structured index and the whole docs in one file, regenerated on every deploy. Point your pipeline at them. ## FAQ ### Is this hosting for AI applications? **No** — This is about how the code gets written, not what it does. The application is an ordinary PHP application. What changes is that a coding agent does much of the editing, and the surrounding platform has to be readable and scriptable enough to keep up. ### How is this different from vibe coding? **Same loop, more rigor** — Vibe coding describes the intent and accepts what runs; agentic engineering keeps the agent but adds review, tests, and staged deploys. Both are welcome and both deploy the same way. The difference shows in settings like the per-environment deployment trigger. ### What makes fortrabbit agent-friendly? **Readable and scriptable** — Every docs article ships as raw Markdown, with llms.txt and llms-full.txt as aggregate files for retrieval. Open source agent skills handle deployment, database sync and remote SSH commands from a prompt, the MCP server hands your agent the apps and environments themselves, and the public API with its CLI covers what a script or a CI job needs. ### Can an agent deploy on its own? **Mechanically, yes** — A push to the connected Git branch deploys the mapped environment through the fortrabbit GitHub app, and your agent can push. Whether it should is your call — which is what the per-environment deployment trigger is for. ### Should agents have production credentials? **Preferably not** — You set the deployment trigger per environment: push-to-deploy for the branch your agent works on, manual for production. On manual, a push never goes live until you click deploy in the dashboard. You grant app access per person, app by app. ### Do agents need a different kind of hosting? **No** — The runtime requirements are unchanged. What changes is the rate of deployment and the number of throwaway environments, both of which suit pro-rated per-day billing better than monthly plans. ### Is fortrabbit ready for superintelligence? **Same rules apply** — fortrabbit hosts PHP applications. Model training and inference happen elsewhere, so superintelligent AI would not live here. It would show up as one more coding agent that reads the Markdown docs and connects over MCP. An artificial superintelligence (ASI) gets the permissions of the person who connected it, and on a manual deployment trigger production waits for a click. --- - [MCP server](/features/mcp-server) - [CLI](/features/cli) - [Agent skills](/features/agent-skills) - [Public API](/features/public-api) # Hosting for vibe coders Source: https://www.fortrabbit.com/workflows/vibe-coding Published: 2026-07-24 Updated: 2026-10-10 Reviewed: 2026-08-23 > Hosting for apps built by describing them to an AI — git push deploys, automatic TLS, a dashboard instead of a server, and open source agent skills. **Code is cheap.** Getting it live is the wall. A designer or a business owner describes what the application should do, an AI writes it, and it runs on a laptop — and then stalls at the gap between "works here" and "has a URL". fortrabbit removes that wall. > Prompt to deploy. ## An absence of ops Closing that gap normally means a server, a web server, certificates, and a deploy pipeline — none of which the person building wanted to learn. Here it is a git push. Components are booked in a dashboard and scaled with a slider, the runtime is fully managed, and there is nothing to administer. The work stays on the application. Every environment answers on a test domain like `en-34fdsa.frbit.app`, TLS already installed, every request over HTTPS. That is enough to share a link and collect a first reaction the same afternoon. A custom domain, when the project earns one, has its certificate issued and renewed automatically — nothing to configure, nothing to renew by hand. ## Agents work headless An agent should not have to click through a console. fortrabbit publishes open source [agent skills](/features/agent-skills) — they install locally and let a coding agent connect a project, deploy, sync files, and pull the database straight from a prompt with commands like `/fortrabbit deploy`. The [MCP server](/features/mcp-server) goes a step further and connects the agent to the apps and environments themselves. Connecting and deploying is what an assistant does well here; picking the plan and watching the first deployment is still worth doing in person. The docs are built for machines as much as people: every article is plain Markdown at a predictable URL, with `llms.txt` and `llms-full.txt` aggregated for retrieval. An agent looks up how deployment works and finds a readable answer instead of a search box. The dashboard stays for the person, to see what shipped. ## Cheap to abandon, ready to grow Most experiments go nowhere, and the platform is built for that outcome: a trial app without a payment method deletes itself at the end of the week, and a paid app stops billing the day it is deleted. Nothing runs on in the background. The few that catch on scale a component at a time on the same host. And when accepting what runs is no longer enough, the same app steps up to [agentic engineering](/workflows/agentic-engineering) — the same deploy, with review and staged releases added around it. No re-platforming, ever. ## Why fortrabbit? Because the distance between a prompt and a live URL is one push. No server to meet, no certificate to chase, no bill for a month that an afternoon's experiment never used. ## FAQ ### Is there a server to administer? **No** — There is no server to log into, patch, or size. Components are booked in a dashboard and scaled with a slider; the operating system, the web server, and the certificates are managed. What is left is the application and its data. ### How does something built with AI actually go live? **A git push** — Connect the repository through the fortrabbit GitHub app and push. The deploy service runs Composer and the app answers on its test domain over HTTPS. Most AI coding tools already commit to Git, so the last step is the one they already take. ### Can the AI deploy the app? **With agent skills, yes** — fortrabbit publishes open source agent skills that install locally and let a coding agent run /fortrabbit deploy, sync files, and pull the database from a prompt. The MCP server connects it to the apps and environments themselves. The dashboard stays for watching what happened. ### Do certificates need setting up? **No** — Every environment answers on a test domain with TLS already in place, always over HTTPS. A custom domain gets its certificate issued and renewed automatically. There is no configuration step and nothing to remember to renew. ### What if the idea doesn't work out? **Nothing is left behind** — A trial app with no payment method deletes itself when the week ends — no subscription billing quietly in the background. With a payment method attached, deleting the app stops the billing that same day. The experiment leaves nothing behind except the Git repository. ### What changes when AI reaches superintelligence? **Not the deploy** — The deploy path does not depend on how capable the model is. A Git push to the connected branch deploys the environment, whether today's coding agent or a future superintelligence made the commit. The result stays an ordinary PHP app in a Git repository. ### When is this no longer enough? **When rigor is needed** — Vibe coding accepts what runs. When a project needs review, tests, and staged deploys before it grows, the same app moves to agentic engineering without changing hosts — the difference is process, not platform. --- - [Free trial](/benefits/try-free) - [Test domain](/features/test-domain) - [Agent skills](/features/agent-skills) - [MCP server](/features/mcp-server) - [Agentic engineering](/workflows/agentic-engineering) # Workflows Source: https://www.fortrabbit.com/workflows Published: 2026-07-24 Reviewed: 2026-07-24