- handbook
- Company
- Company
- Board
- Communications
- Decision making
- Guides
- KPIs and OKRs
- principles
- Remote Work
- Security
- Asset Management Policy
- Business Continuity & Disaster Recovery Policy
- Information Security Roles and Responsibilities
- Operations Security Policy
- Risk Management Policy
- Third-Party Risk Management Policy
- Human Resources Security Policy
- Access Control Policy
- Incident Response Plan
- Cryptography Policy
- Information Security Policy and Acceptable Use Policy
- Secure Development Policy
- Data Management Policy
- strategy
- values
- Operations
- Product
- Feedback
- Market Segments
- Metrics
- Node-RED Dashboard
- personas
- Pricing Principles
- Principles
- Responsibilities
- Strategy
- Versioning
- Customer department
- Customer
- Customer Success
- Hubspot
- Marketing
- How we work
- Marketing
- Video
- Customer Stories
- Social Media
- blog
- Community
- Marketing - Website
- Webinars
- FlowFuse Messaging
- Sales
- Engineering & Design Practices
- Design
- Engineering
- Certified Nodes
- contributing
- Front End
- Packaging Guidelines
- Platform Ops
- Deployment
- Incident Response
- Observability
- Production Environment
- FlowFuse Dedicated
- Staging Environment
- Project Management
- Releases
- Security Policy
- tools
- Website A/B Testing
- Internal Operations
- People Ops
# FlowFuse Dedicated
FlowFuse Dedicated is our product offering where we will host a dedicated instance of the platform for a customer.
This is a guide for the setup and delivery of a dedicated instance.
# Pre-deployment
In order to create the dedicated instance, some information will be required from the customer.
- A domain name or sub domain name to host the platform on.
- By default, we will offer to host the platform under a domain of
<customer>.flowfuse.io. - The core platform (
app.), broker (mqtt.) and hosted instances will be made available under this domain. - The base domain,
<customer>.flowfuse.io, will redirect toapp.<customer>.flowfuse.io - All traffic to the domain will be on port 443 - including the Device Agent MQTT connection
- If the customer requests to use their own (sub-)domain, they will need to setup their DNS to point at the AWS Route53 end-point once it has been created.
- By default, we will offer to host the platform under a domain of
- Choice of AWS region. We default to
eu-west-1but customers may want to choose one more local to them. Not all AWS regions are equal and we may need to review their choice for suitability. - Capacity planning. Whilst the platform will scale to meet demand, we want to sure we provision it at a suitable level for their intended usage. Understanding their planned usage and growth rate will help us pick the right node size for the cluster.
- Team/Instance types. We will default to creating equivalent Team and Instance types as we use on FFCloud. If a customer has specific needs in this area, this should be identified prior to deployment.
- SSO Configuration. As with FFCloud, if the customer plans to integrate with their SSO provider, we will need to capture the necessary information. This can be done after the initial deployment.
# Deployment
An issue should be raised in the CloudProject repository using the Dedicated Checklist template and assigned to the member of the engineering/ops team who will do the setup.
This checklist covers the follow items:
- Create a new AWS sub-account for each dedicated env.
- Create user accounts for the ops team
- Use Terraform to setup initial cluster
- Setup grafana monitoring - including all the necessary alerting
- Setup initial admin account - store details in 1Password
- Setup initial Stacks, Instance Types and Team Types
- Setup SSO for customer
- Create initial account for customer admin user (if we’re giving them admin access)
# Migration
For existing customers of FFCloud who are choosing to move to a FFDedicated environment, we need to consider how to migrate their existing account. This will need to be considered on a case-by-case basis in discussion with the customer as there are a number of challenges around providing a seamless migration.
For example, we cannot migrate access tokens between platforms. This will require devices to be reprovisioned with new credentials as well as have their device.yml updated to point to the new platform URL.
# Maintenance
We will agree a maintenance policy with the customer to fit their needs. We will require the code to be kept up to date - the question is how we schedule updates.
# FlowFuse Code Updates
We can either do CI/CD as we do for FF Cloud, or apply updates following each monthly release.
# k8s Updates
We will coordinate maintenance windows with the customer for when we need to apply updates to the underlying k8s infrastructure as this will require restarts of their Node-RED instances.