Installing Airtable alternative Baserow with Nuon

For many SaaS vendors, offering their products as self-hosted or single-tenant deployments for enterprise customers is both an opportunity and a challenge. Enterprises often want to run software inside their own cloud accounts for security, compliance, or data sovereignty reasons—but delivering and maintaining those deployments at scale can be complex and time-consuming.

Baserow, an open-source Airtable competitor, is a great example. It’s a powerful no-code database platform that many teams want to self-host to gain more control over their data. But setting up Baserow in multiple customer environments involves provisioning infrastructure, managing certificates, configuring multiple services, and tuning deployments for reliability.

This is exactly the kind of scenario Nuon is built for and we call it Bring Your Own Cloud or BYOC. Nuon provides software vendors or enterprises with a control and data plane that automates the deployment and management of cloud-native applications directly into customer cloud accounts. With Nuon, software vendors can offer fully managed, self-hosted versions of their apps without reinventing infrastructure automation for every customer.

In this post, we’ll walk through how we built and configured Baserow on Nuon —showing how software vendors can deliver enterprise-grade, self-hosted deployments quickly and repeatably.

What is Baserow

Baserow is an open-source, no-code database and Airtable competitor that lets users build and manage databases without writing code. It features a simple, collaborative interface for creating tables, fields, and records, along with automation and integrations that make it ideal for teams. Common use cases include project management, trouble ticketing, and CRM systems.

Its competitors include Airtable, Smartsheet, monday.com, ClickUp, NocoDB, Appsmith, and Budibase. For enterprises that need data sovereignty, enhanced security, and customization capabilities, self-hosting Baserow is often the preferred option. However, deploying and managing a complex application like Baserow across multiple customer environments can be operationally difficult.

Nuon removes much of this complexity by handling the VPC and Kubernetes infrastructure provisioning, configuration management, deployment automation and day-2 monitoring and maintenance required to deliver Baserow as a vendor-managed, customer-hosted solution.

Overview of the Baserow App Config

An App Config in Nuon is a declarative specification that defines how an application should be deployed into a customer’s cloud account. The Baserow app config includes multiple application services, supporting infrastructure notably a VPC, Kubernetes cluster and subnets, and templated inputs for different customer installations.

The Baserow App Config is located in this Nuon GitHub repository of example app configs.

Kubernetes Infrastructure

In this example, each Baserow installation runs inside its own isolated Amazon EKS (Elastic Kubernetes Service) cluster, provisioned automatically by Nuon. The cluster configuration is defined in sandbox.toml and includes the AWS region, node group settings, and scaling parameters.

The app configuration (app config) specifies instance types, minimum and maximum node counts. An optional configuration is to also use Karpenter for node autoscaling. The app config also sets up essential Kubernetes add-ons—such as the AWS Load Balancer Controller for ingress, external-DNS for automated DNS management, and IRSA (IAM Roles for Service Accounts) for secure pod-level AWS permissions to access S3 buckets. This standardized Kubernetes foundation allows vendors to deploy complex applications like Baserow consistently across many customer environments without manually managing clusters or networking.

Core Application Components

Baserow consists of several services that work together:

• Frontend (web-frontend) — Next.js-based user interface
• Backend WSGI — Django REST API server
• Backend ASGI — WebSocket server for real-time collaboration
• Celery Workers — Background task processing
• PostgreSQL — Primary database
• Redis — Caching and message broker

AWS Infrastructure Components

In addition to the application itself, the app config provisions supporting AWS resources. These include S3 for object storage, TLS certificates for secure endpoints, and multiple Application Load Balancers (ALBs) to handle frontend and backend traffic.

S3 Storage

Baserow uses S3 for file uploads (e.g., csv files to populate tables) and object storage. The Nuon app config includes an S3 component that provisions a dedicated bucket with versioning, KMS encryption, and secure IAM roles via IRSA. For example:

resource "aws_iam_role" "baserow_role" {
  name               = "${var.install_id}-nuon-baserow-role"
  assume_role_policy = data.aws_iam_policy_document.baserow_trust_policy.json

  inline_policy {
    name   = "${var.install_id}-nuon-baserow-role-inline-bucket-access-policy"
    policy = data.aws_iam_policy_document.baserow_bucket_access_policy.json
  }
}

The IAM role is then referenced in Helm values so that Baserow pods can access S3 without storing AWS credentials:

backend:
  asgi:
    serviceAccount:
      create: true
      annotations:
        eks.amazonaws.com/role-arn: "{{.nuon.components.baserow_s3_bucket.outputs.role_arn}}"

TLS Certificate

TLS certificates for Baserow are configured declaratively in the certificate.toml component. Nuon uses this configuration to automatically provision a single certificate through AWS Certificate Manager with DNS validation. This certificate secures both the frontend and backend domains, ensuring encrypted traffic for all customer environments without any manual certificate management.

[[components]]
type = "certificate"
name = "certificate"

[components.inputs]
domain_name = "{{ .nuon.install.sandbox.outputs.nuon_dns.public_domain.name }}"
subject_alternative_names = [
  "api.{{ .nuon.install.sandbox.outputs.nuon_dns.public_domain.name }}"
]

The subject_alternative_names field includes the API subdomain, allowing one certificate to cover both the main frontend domain and the backend API domain for each installation.

Application Load Balancers

Baserow requires two ALBs — one for the frontend web interface and one for the backend API and WebSocket connections. The backend ALB includes custom listener rules to support WebSockets, achieved by modifying the AWS Load Balancer Controller Helm configuration.

The ALB components in the TOML files define how external HTTPS traffic is routed to services running inside the Kubernetes cluster. Each ALB maps port 443 (HTTPS) to a specific Kubernetes service name and port within the target namespace, ensuring that frontend and backend traffic are directed correctly. The configuration specifies the service name, service port, and namespace for the target group, and it also sets a health check path so that the load balancer can continuously verify pod readiness. This declarative setup allows Nuon to provision fully functional ingress for both the Baserow web frontend and backend API without writing any custom ingress manifests.

Helm Configuration

The main application settings live in components/values/baserow/values.yaml. Some key configurations include:

Resource Requests and Limits

frontend:
  resources:
    requests:
      memory: "512Mi"
      cpu: "500m"
    limits:
      memory: "2Gi"
      cpu: "1500m"

backend:
  celery:
    resources:
      requests:
        memory: "512Mi"
        cpu: "500m"
      limits:
        memory: "2Gi"
        cpu: "1500m"

Baserow benefits from fairly beefy instance sizes — t3a.large and above — to avoid OOMKills during task processing. The frontend and backend.celery pods use the most resources so requests and limits are set to guarantee enough compute resources.

Health Checks

frontend:
  readinessProbe:
    initialDelaySeconds: 0
    periodSeconds: 0
    successThreshold: 1

These were tuned (disabled) to handle slower startup times and improve pod stability. Without adjusting the probes, ALB health checks to the pods may fail, making the services unreachable.

Multi-Domain Configuration

config:
  publicBackendUrl: "https://api.{{.nuon.install.sandbox.outputs.nuon_dns.public_domain.name}}"
  publicFrontendUrl: "https://{{.nuon.install.sandbox.outputs.nuon_dns.public_domain.name}}"

This configuration ensures that both the frontend and backend services are automatically exposed under the correct subdomains, with Nuon injecting the appropriate domain values at deploy time for each customer environment.

ALB Health Check Compatibility

frontend:
  extraEnv:
    - name: BASEROW_EXTRA_ALLOWED_HOSTS
      value: "*"

This ensures ALB health checks don’t get blocked by Django’s ALLOWED_HOSTS setting. Without this setting, the ALBs were not able to reach their health check paths in the pods.

Configuration Templating

Nuon uses Go templates to inject environment-specific values at deploy time, such as:

• {{.nuon.install.id}} — Unique installation ID
• {{.nuon.inputs.inputs.baserow_release}} — Image tag
• {{.nuon.components.baserow_s3_bucket.outputs.bucket_name}} — Provisioned S3 bucket
• {{.nuon.install.sandbox.outputs.nuon_dns.public_domain.name}} — Generated domain name

This templating allows a single app config to work across many different customer environments without hardcoding any environment-specific values. For example, if the software vendor or enterprise needed to upgrade the Baserow release for a specific install, it would simply use the Update Inputs section of the Nuon dashboard which would trigger a re-deployment of the Baserow Helm component to the new Baserow release.

Persistent Storage

For local storage, Baserow uses persistent volumes with S3 integration:

persistence:
  enabled: true
  accessModes:
    - ReadWriteOnce
  storageClassName: "gp2"
  size: "20Gi"

This gives a hybrid storage model — local caching plus durable object storage.

Creating and Syncing the Baserow App Config with Nuon

The operator of Nuon uses the CLI to create the app config name and sync the git-backed app config to the Nuon control plan.

git clone https://github.com/nuonco/example-app-configs
cd ~/example-app-configs/baserow
nuon auth login
nuon orgs select
nuon apps create -n baserow
nuon apps sync

The components are built as OCI artifacts and placed in a cloud container registry.

Nuon Runner and Permissions

Under the hood, each installation begins with provisioning a Nuon runner inside an EC2 instance in the customer’s AWS account. The runner is a lightweight control plane that Nuon uses to execute deployment plans securely and in isolation for each customer. Separating the runner from the Baserow Kubernetes infrastructure is a key design element, allowing the Nuon control plane to still be able to communicate with the runner if the app becomes unhealthy.

To set this up, Nuon provides a CloudFormation stack that the customer installs in their account. This stack creates the required IAM roles, permission boundaries, and trust policies that allow the runner to operate with just the right level of access. Permission boundaries are applied to ensure the runner cannot exceed the scope defined by the vendor’s app config—providing a strong security guarantee while still enabling automated provisioning of infrastructure like EKS clusters, S3 buckets, certificates, and load balancers. All subsequent actions, from infrastructure creation to Helm deployments, happen through the runner using these scoped roles, so vendors never need direct access to the customer’s AWS account.

Deploying Baserow with Nuon

Once the app config is defined, deploying Baserow into a customer’s AWS account follows a clear, structured workflow.

1. Vendor Initiates Installation
The process begins in the Nuon dashboard, where the vendor selects the Baserow app config and starts a new installation. At this stage, they provide environment-specific parameters defined in inputs.toml.

Typical inputs include the AWS region, Kubernetes node count and instance type, and the Baserow release version to install. These inputs are templated into the app config at deploy time, ensuring each customer environment is configured correctly without manual edits.

2. Customer Onboarding
The customer connects their AWS account to Nuon using a CloudFormation stack. This grants Nuon the IAM permissions needed to provision and manage resources within the customer’s account.

3. Plan and Approvals
Nuon then generates an installation plan, what we call a workflow, which goes through a series of approval gates. At each stage, the vendor can review and approve the planned actions before they’re executed.

For example, during the Helm approval step, Nuon shows a detailed plan of all Kubernetes resources to be added, changed, or destroyed (such as ConfigMaps, Deployments, and Services). Vendors can approve, retry, or deny the plan directly from the dashboard, giving them full control over the rollout.

Alternatively, the operator of Nuon can decide to Approve All and will not be prompted for approvals.

4. Automated Deployment
Nuon then executes the installation plan step by step, pausing for approvals at each major stage. For example, the vendor approves the creation of the EKS cluster, then the S3 bucket and IAM roles, followed by Helm chart deployment, the certificate, load balancers and DNS records. This gated approach gives vendors full visibility and control during the rollout while Nuon automates the underlying infrastructure provisioning and application deployment.

5. Access
After deployment, the Baserow instance is available at the customer’s configured domain, such as: https://<install-id>.nuon.run

This workflow provides a balance between automation and control — vendors get fully automated infrastructure provisioning and application deployment, while still retaining checkpoints to review and approve critical changes along the way.

Day-2 Operations

Beyond installation, Nuon streamlines Day-2 operations through declarative actions defined in the app config. For Baserow, this includes a built-in health check action that verifies the deployment is running correctly across all components. Vendors can run this action post-install or during maintenance to quickly validate the state of customer environments without manual checks.

In addition, vendors can expose actions like deployment_restart (to restart a specific component or service), kubectl_logs (to tail or aggregate logs across pods), scale_component (to adjust replica counts dynamically), http_healthcheck (to probe custom HTTP endpoints), and db_backup (triggering a safe database snapshot) as part of their operational toolkit. These actions can be executed ad hoc or included in scripted maintenance workflows, giving teams powerful control over customer environments without needing manual SSH or console access.

Key Technical Challenges Solved

Building the Baserow app config involved a few non-trivial challenges:

Dual Load Balancer Architecture — Supporting both frontend and backend ALBs with WebSocket routing.

Resource Tuning — Determining minimum viable instance sizes for stable performance.

IAM Security — Using IRSA for S3 access to avoid static AWS credentials.

Health Check Compatibility — Configuring BASEROW_EXTRA_ALLOWED_HOSTS to work with ALB checks.

Multi-Domain Certificate — Issuing a TLS cert for both frontend and API subdomains.

Conclusion

Deploying applications like Baserow across multiple customer environments typically requires significant DevOps effort. Nuon turns this into a smooth, automated process — handling infrastructure provisioning, configuration management, and deployment orchestration.

For software vendors, this means:

• Faster time to market for self-hosted offerings than DIY
• Less operational overhead for each customer deployment
• Consistent, automated installs at scale

For enterprises, Nuon provides:

• Data sovereignty — everything runs in their own AWS accounts
• Enhanced security and control
• Customization options for their unique needs
• Automated updates and lifecycle management

The Baserow app config is a good example of deploying a multi-service, stateful application using Nuon. The patterns — from IRSA integration to multi-domain certificates — apply broadly to many vendor-managed, customer-hosted SaaS products.