You need Prometheus. Then an exporter for your specific database. Then Grafana (or another dashboard). Then Alertmanager. Then you need to write the alert rules, configure notification channels, test that the alerts actually fire, and figure out why they fire at 3am for things that aren't real emergencies.

And this is before you've handled certificate rotation for the exporter, dealt with the Prometheus scrape interval tuning, or figured out why your dashboard queries are returning No data.

With Filess Dedicated databases, all of this ships by default. Here's what you get and how it's built.

Percona Monitoring and Management (PMM), Already Running​

Every Dedicated database includes a PMM instance preconfigured and connected to your database. You don't install anything. You don't run any agents. It's just there.

PMM is Percona's open-source database observability platform. It gives you:

• Query Analytics (QAN): Which queries are slowest? Which ones are running most frequently? Which ones have the highest I/O impact? PMM captures this at the query level — not just at the connection level.
• Performance metrics: CPU, memory, disk I/O, and database-specific metrics (buffer pool hit rate, replication lag, connection count, lock waits, etc.) updated every few seconds.
• Database Advisors: Automated checks that scan your database configuration and data patterns and surface recommendations. Things like "this index is never used" or "your innodb_buffer_pool_size is undersized for your working set."
• Explain plans: Run EXPLAIN on any slow query directly from the PMM UI without opening a terminal.

This is the same tooling that DBAs at large-scale deployments use. It's available to you on a $20/month database.

Alert Rules: Three Signal Types​

For automated alerting, we expose a structured alert rule system on top of Prometheus. Three signal types are supported today:

1. CPU Usage​

Rule: cpu_usage > 80% for 5 minutes

The threshold is expressed as a percentage of the database's allocated CPU. Internally, CPU allocation is expressed in "units" (1 unit = 0.5 vCPU), so a 4-unit database has 2 vCPUs, and a CPU alert at 80% fires when sustained usage exceeds 1.6 vCPUs.

The forMinutes parameter controls how long the condition must be true before the alert fires. Setting it to 1 means the alert fires within a minute of the threshold being crossed. Setting it to 15 means sustained high CPU for 15 minutes — useful for workloads with legitimate traffic spikes.

2. Memory Usage​

Rule: memory_usage > 90% for 3 minutes

Memory allocation is also expressed in units (1 unit = 500 MiB). The alert fires when RSS memory usage exceeds the threshold percentage of total allocated memory.

Memory alerts at 90%+ on a database are a serious signal. It typically means either:

• Your working set has outgrown your plan (time to scale up).
• A query is performing a full table scan without a covering index and pulling enormous amounts of data into the buffer pool.
• A connection pool is leaking and connections are accumulating unreleased memory.

PMM's query analytics will usually tell you which one.

3. Downtime​

Rule: database is unreachable

The downtime rule doesn't take a threshold — it's a binary check. If the database stops responding to health checks for the configured forMinutes window, the alert fires.

This is the most critical alert type. It fires on actual outages, not capacity pressure.

Creating Alert Rules via API​

Alert rules are fully automatable:

curl -X POST https://api.filess.io/v1/organizations/my-org/namespaces/prod/databases/42/alert-rules \
  -H "Authorization: Bearer $FILESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "cpu_usage",
    "thresholdPercent": 80,
    "forMinutes": 5,
    "name": "High CPU"
  }'

Response:

{
  "id": 17,
  "name": "High CPU",
  "type": "cpu_usage",
  "thresholdPercent": 80,
  "forMinutes": 5,
  "isEnabled": true,
  "status": "ok",
  "createdAt": "2026-04-04T10:00:00Z"
}

You can also manage alert rules via the dashboard. Rules can be enabled/disabled without deleting them — useful when you're doing planned maintenance and want to silence alerts temporarily.

How Alerts Are Evaluated​

The evaluation pipeline uses Prometheus as the underlying data source. Here's the simplified flow:

Database → Exporter → Prometheus scrape → PromQL evaluation → AlertManager → Notification

Our backend has a direct integration with Prometheus. When you create or update an alert rule, we generate the corresponding PromQL expression and register it with Alertmanager. The rule includes the for duration — Prometheus won't fire the alert until the condition has been continuously true for that duration.

When an alert fires, Alertmanager routes the notification to our backend, which then:

1. Records an AlertEvent in the database with status firing.
2. Determines which users in the namespace should be notified.
3. Sends notifications via the configured channels.

When the condition resolves, another event is recorded with status resolved, and a resolution notification is sent.

Notification Channels​

Currently supported notification channels:

• Email: Delivered to all users in the namespace with notification access.
• In-app notifications: Available in the dashboard notification center.

Webhook notifications and Slack integration are on the roadmap.

Alert Event History​

Every alert firing and resolution is stored as an event. This gives you a timeline of incidents:

2026-03-12 03:14 UTC — cpu_usage fired: CPU at 94% for 5 minutes
2026-03-12 03:47 UTC — cpu_usage resolved: CPU back to 23%
2026-03-15 11:02 UTC — memory_usage fired: Memory at 91% for 3 minutes
2026-03-15 11:09 UTC — memory_usage resolved

This timeline is useful for:

• Post-mortems: correlating an alert firing with a deployment, traffic spike, or schema change.
• Capacity planning: how often are you hitting CPU or memory limits? Is it getting more frequent?
• On-call handoffs: the incoming responder can see what's been happening without reading through a chat thread.

The Prometheus Architecture Behind It​

Our monitoring stack is region-scoped. Each region runs a shared Prometheus instance that scrapes all databases in that region. The per-database metrics are namespaced by database ID to prevent cross-tenant data leakage.

The connection config is encrypted at rest:

HostingRegion {
  prometheusEndpoint:         "https://prometheus.eu.filess.io"
  prometheusUsername:         "filess-backend"
  prometheusPasswordEncrypted: "AES256GCM-encrypted-value"
}

Credentials are decrypted in memory at query time. They're never stored in plaintext in the database.

When you query database metrics from the dashboard, our backend:

1. Looks up the region's Prometheus endpoint.
2. Decrypts the credentials.
3. Executes a scoped PromQL query against Prometheus.
4. Returns the data to the frontend.

You never hit Prometheus directly. You don't manage credentials. You don't write PromQL.

What You're Not Doing​

Let's be explicit about the yak shaving you're avoiding:

The goal is for you to spend your time understanding what your database is doing, not configuring the tools that watch it.

Getting Started​

Alert rules are available on all Dedicated plans. PMM access is included on Dedicated plans.

To add your first alert rule:

1. Navigate to your database in the Filess dashboard.
2. Go to Monitoring → Alert Rules.
3. Click Add Rule, choose the type, set the threshold and duration.
4. Save. That's it.

The next time your database hits 80% CPU for 5 minutes, you'll know about it before your users do.

Explore Filess Dedicated Databases →

Then you try to deploy it.

You either wrangle with a VPS, a Dockerfile, a reverse proxy, SSL certificates, and systemd units — or you pay a managed platform that doesn't understand docker-compose.yml natively and forces you to rewrite everything in their DSL.

Filess Hosting takes your docker-compose.yml and runs it on Kubernetes, with zero Kubernetes knowledge required. Here's the full technical picture of what happens when you push a commit.

The Build Pipeline: From Git to Running Container​

When you trigger a deployment (manually, via API, or automatically on git push), the pipeline goes through three phases.

Phase 1: Preflight Analysis​

Before building anything, we analyze your repository:

• Parse the docker-compose.yml and validate all service definitions.
• Resolve ${VARIABLE} interpolations against your environment variables, catching missing required variables early with clear error messages.
• Validate exposed ports, Dockerfile paths, build context paths, and Docker build args.
• Detect the build system: if you have a Dockerfile, we use it. If you have a docker-compose.yml with build: stanzas, we build all services. If neither, we fall back to Nixpacks for automatic detection.

This step fails fast. There's no 10-minute wait for a build to fail because you had a typo in your Compose file.

Phase 2: Building — Kaniko in the Cluster​

We build container images using Kaniko, Google's daemonless Kubernetes-native image builder. This runs entirely inside the cluster — no Docker daemon, no privileged containers.

The build process:

1. A Kaniko job is created in your project's Kubernetes namespace.
2. Kaniko clones your repository (via HTTPS or SSH, depending on your repo credential configuration).
3. It executes your Dockerfile steps layer by layer.
4. The final image is pushed to our private container registry with a content-addressed tag based on the commit SHA.

Build logs stream in real time to the dashboard. If the build fails, the error is classified by origin (build_failed, preflight_failed, registry_error, etc.) and surfaced with a user-facing explanation rather than a raw Kubernetes error.

Phase 3: Runtime — Kubernetes Deployments​

Once the image is in the registry, we apply Kubernetes resources:

• A Deployment for each service, with resource limits derived from your plan.
• ConfigMaps for non-sensitive environment variables.
• Secrets for sensitive environment variables (anything you mark as secret in the dashboard).
• PersistentVolumeClaims for any volumes you've defined.
• An HTTPRoute (Gateway API) that maps your custom domain or subdomain to the main service.
• A TLS certificate via our cert-manager integration.

The deployment is rolled out with a rolling update strategy. Zero downtime by default.

The Docker Compose Translator​

The most technically interesting part is how we translate docker-compose.yml into Kubernetes resources. This isn't a direct 1:1 mapping — Compose and Kubernetes have different models — so we built our own translator.

A docker-compose.yml like this:

services:
  web:
    build: .
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: ${DATABASE_URL}
      REDIS_URL: redis://cache:6379
    depends_on:
      - cache
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

  cache:
    image: redis:7-alpine
    volumes:
      - redis_data:/data

volumes:
  redis_data:

Gets translated into a ComposeRuntimeSpec:

{
  "version": 1,
  "composePath": "docker-compose.yml",
  "mainService": "web",
  "mainServiceSlug": "web",
  "mainPort": 3000,
  "services": [
    {
      "name": "web",
      "slug": "web",
      "runtimeName": "my-app-web",
      "image": "registry.filess.io/my-project/web:sha256-abc123",
      "ports": [3000],
      "env": [
        { "key": "DATABASE_URL", "runtimeEnvKey": "DATABASE_URL" },
        { "key": "REDIS_URL", "value": "redis://my-app-cache:6379" }
      ],
      "healthcheck": {
        "command": ["CMD", "curl", "-f", "http://localhost:3000/health"],
        "intervalSeconds": 30,
        "timeoutSeconds": 10,
        "retries": 3
      }
    },
    {
      "name": "cache",
      "slug": "cache",
      "runtimeName": "my-app-cache",
      "image": "redis:7-alpine",
      "ports": [],
      "env": [],
      "volumes": [{ "mountPath": "/data", "claimName": "my-app-redis-data" }]
    }
  ],
  "buildTasks": [
    {
      "name": "web",
      "slug": "web",
      "contextPath": ".",
      "dockerfilePath": "Dockerfile",
      "dockerBuildArgs": [],
      "imageTag": "registry.filess.io/my-project/web:sha256-abc123"
    }
  ]
}

This spec is stored in the database and used to idempotently reconcile the Kubernetes state. If you push a new commit, we diff the spec and apply only what changed.

Variable Interpolation​

We implement the full Docker Compose variable interpolation spec:

This matters because many real docker-compose.yml files use these constructs to make environments portable.

Preview Environments​

This is the feature that changes how you do code review.

Every branch (or pull request) can get its own ephemeral deployment at a unique URL:

https://feature-login-redesign--my-app.filess.app

The URL is derived from a hash of the branch name and project ID — deterministic and permanent for the lifetime of the branch. When the PR is merged, the preview environment is automatically cleaned up.

The Prisma model behind this:

HostingPreviewEnvironment {
  sourceType: branch | commit | tag
  sourceRef:  "feature/login-redesign"
  subdomain:  "feature-login-redesign--abc123"
  closedAt:   null (open) or DateTime (closed)
}

Preview environments share the same build infrastructure as production. They use the same container image (built once, deployed twice) but get their own Kubernetes namespace, their own environment variables, and their own URL.

Persistent Volumes​

Stateful apps need persistent storage. You can define volumes in the dashboard or inherit them from your docker-compose.yml:

volumes:
  uploaded_files:
    driver: local

Each volume becomes a PersistentVolumeClaim in Kubernetes, mounted into the container at the specified path. Mount paths must be under /app or /data — we enforce this to prevent accidental mounts of system directories.

Volume sizes are specified in GiB and billed accordingly. Volumes survive deployments: if you push a new commit, your uploaded files stay where they were.

Health Checks and Restart Policies​

If your docker-compose.yml defines a healthcheck, we translate it into a Kubernetes livenessProbe and readinessProbe. This means:

• Kubernetes won't route traffic to your pod until it's ready.
• If a pod becomes unhealthy, Kubernetes replaces it automatically.
• The deployment rollout waits for new pods to become healthy before terminating old ones.

Restart policies are configurable:

• Always (default): Restart on any exit.
• OnFailure: Only restart on non-zero exit codes.
• Never: Don't restart. Useful for one-shot job containers.

Custom Domains and TLS​

Point any domain at Filess by adding a CNAME record:

app.yourdomain.com → cname.filess.app

Add the domain in the dashboard. We verify DNS ownership and provision a TLS certificate automatically. The certificate auto-renews before expiration. You don't manage any of this.

For *.yourdomain.com wildcard certificates on your domain, contact support.

Maintenance Mode​

You can enable maintenance mode on any project without a deployment. When enabled, all traffic returns a configurable HTTP status code (503 by default) with a static maintenance page. This is a gateway-level feature — your containers don't need to change.

Bypass the maintenance page during a live incident by sending the X-Filess-Bypass-Maintenance header (value configured in the dashboard). This lets your team verify the fix before taking the site out of maintenance mode.

Deployment Rollback​

Every deployment is immutable. The container image for commit abc123 will always be registry.filess.io/my-project/web:abc123. Rolling back is just re-deploying a previous commit — the image is already in the registry, so it's fast.

# Roll back via API
curl -X POST https://api.filess.io/v1/.../deployments/{previousDeploymentId}/rollback \
  -H "Authorization: Bearer $FILESS_TOKEN"

There's no "undo" button that modifies history. You roll forward to a previous state. Clean audit trail.

Build Logs and Runtime Logs​

All logs are available in the dashboard and via API:

• Build logs: The full Kaniko output for each build. Captured and stored so you can debug failures from last week without hunting through a CI system.
• Runtime logs: Live and historical logs from your running containers. Filter by service, time range, and log level.

Log redaction is automatic. We scan build and runtime logs for known secret patterns (registry credentials, API keys) and redact them before storing or displaying.

What's Next​

Filess Hosting is built for developers who want to ship, not manage infrastructure. If you've been looking for a platform that respects your existing docker-compose.yml and doesn't ask you to rewrite your entire setup, give it a try.

Pair it with a Filess managed database and you've got a full production stack — app + database — in one dashboard.

Deploy your first app on Filess →

Your CI pipeline runs unit tests. They pass. Your reviewer approves the PR.

You merge. You deploy. Production breaks.

The bug was a subtle interaction between your code and the database schema — something unit tests couldn't catch because they mock the database. Integration tests could have caught it, but your integration test suite either doesn't exist or runs against a shared staging database that's full of dirty state from the last developer who also tested there.

The real fix is an ephemeral database per PR: a fresh database, identical to production schema, provisioned when the PR opens and destroyed when it merges. Your integration tests run against it. Nothing shares state between PRs.

Filess has two APIs. Knowing which one to use matters.

Two APIs, Two Use Cases​

Filess exposes two distinct REST APIs:

For ephemeral CI/CD databases, the Shared API is the right choice. It's designed for this: three fields in, connection string out. No org slugs, no namespace slugs, no plan configuration.

The Dedicated API (backend.filess.io) is for long-lived databases organized within your team's Organizations and Namespaces — more control, more configuration, better suited for stable environments.

The Shared API: Three Endpoints​

GET    https://api.filess.io/v1/regions       — List available regions
POST   https://api.filess.io/v1/instances     — Create a database
DELETE https://api.filess.io/v1/instances/{id} — Delete a database

That's the entire surface for CI/CD. Clean.

Create an instance​

curl -X POST "https://api.filess.io/v1/instances" \
  -H "Authorization: Bearer <your-jwt-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "identifier": "pr-452-test",
    "region": "4747ed15-34b7-4f41-a80b-387a6a907a1e",
    "motor": "mysql-8.0.29"
  }'

Response — connection details returned immediately, no second request needed:

{
  "msg": "OK",
  "data": {
    "instance": {
      "id": "14f831d2-923c-4352-86d0-10f06c6272ae",
      "name": "pr452test_acceptinch",
      "user": "pr452test_acceptinch",
      "isEnabled": true,
      "identifier": "pr-452-test",
      "host": "z6a.h.filess.io",
      "port": 3306,
      "region": "Spain",
      "password": "dd976df83454d5a9bb259995ae82f222ac82e59d",
      "createdAt": "2026-04-04T10:00:00.000Z"
    }
  }
}

Available motors​

mysql-5.7.38
mysql-8.0.29
mariadb-10.7.4
postgresql-14.4.0
postgresql-15.4.0
mongodb-5.0.9
mongodb-7.0.2

Delete an instance​

curl -X DELETE "https://api.filess.io/v1/instances/14f831d2-923c-4352-86d0-10f06c6272ae" \
  -H "Authorization: Bearer <your-jwt-token>"

Complete GitHub Actions Workflow​

# .github/workflows/integration-tests.yml
name: Integration Tests

on:
  pull_request:
    types: [opened, synchronize, reopened, closed]

jobs:
  test:
    if: github.event.action != 'closed'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Get region ID
        id: region
        env:
          FILESS_TOKEN: ${{ secrets.FILESS_SHARED_TOKEN }}
        run: |
          REGION_ID=$(curl -sf "https://api.filess.io/v1/regions" \
            -H "Authorization: Bearer $FILESS_TOKEN" \
            | jq -r '.data.regions[0].id')
          echo "id=$REGION_ID" >> $GITHUB_OUTPUT

      - name: Create ephemeral database
        id: db
        env:
          FILESS_TOKEN: ${{ secrets.FILESS_SHARED_TOKEN }}
        run: |
          RESPONSE=$(curl -sf -X POST "https://api.filess.io/v1/instances" \
            -H "Authorization: Bearer $FILESS_TOKEN" \
            -H "Content-Type: application/json" \
            -d "{
              \"identifier\": \"pr-${{ github.event.number }}\",
              \"region\": \"${{ steps.region.outputs.id }}\",
              \"motor\": \"mysql-8.0.29\"
            }")

          DB_ID=$(echo $RESPONSE   | jq -r '.data.instance.id')
          DB_HOST=$(echo $RESPONSE | jq -r '.data.instance.host')
          DB_PORT=$(echo $RESPONSE | jq -r '.data.instance.port')
          DB_USER=$(echo $RESPONSE | jq -r '.data.instance.user')
          DB_PASS=$(echo $RESPONSE | jq -r '.data.instance.password')
          DB_NAME=$(echo $RESPONSE | jq -r '.data.instance.name')

          # Build connection URL
          DB_URL="mysql://${DB_USER}:${DB_PASS}@${DB_HOST}:${DB_PORT}/${DB_NAME}"

          echo "db_id=$DB_ID"   >> $GITHUB_OUTPUT
          echo "db_url=$DB_URL" >> $GITHUB_OUTPUT

      - name: Store DB ID for cleanup
        uses: actions/cache/save@v4
        with:
          path: /dev/null  # dummy, we use the key
          key: filess-db-pr-${{ github.event.number }}-${{ steps.db.outputs.db_id }}

      - name: Run migrations
        env:
          DATABASE_URL: ${{ steps.db.outputs.db_url }}
        run: npx prisma migrate deploy

      - name: Run integration tests
        env:
          DATABASE_URL: ${{ steps.db.outputs.db_url }}
        run: npm test -- --testPathPattern=integration

      - name: Delete database on test failure
        if: failure()
        env:
          FILESS_TOKEN: ${{ secrets.FILESS_SHARED_TOKEN }}
        run: |
          curl -sf -X DELETE \
            "https://api.filess.io/v1/instances/${{ steps.db.outputs.db_id }}" \
            -H "Authorization: Bearer $FILESS_TOKEN"

  teardown:
    if: github.event.action == 'closed'
    runs-on: ubuntu-latest
    steps:
      - name: Restore cached DB ID
        id: cache
        uses: actions/cache/restore@v4
        with:
          path: /dev/null
          key: filess-db-pr-${{ github.event.number }}-
          restore-keys: filess-db-pr-${{ github.event.number }}-

      - name: Delete database
        env:
          FILESS_TOKEN: ${{ secrets.FILESS_SHARED_TOKEN }}
        run: |
          # Extract DB ID from the matched cache key
          DB_ID=$(echo "${{ steps.cache.outputs.cache-matched-key }}" \
            | sed 's/filess-db-pr-[0-9]*-//')
          
          curl -sf -X DELETE \
            "https://api.filess.io/v1/instances/$DB_ID" \
            -H "Authorization: Bearer $FILESS_TOKEN"
          
          echo "Deleted database $DB_ID"

A Minimal Shell Helper​

For projects that use multiple CI systems or custom scripts:

#!/usr/bin/env bash
# scripts/filess.sh — Shared API wrapper
set -e

TOKEN="${FILESS_SHARED_TOKEN:?FILESS_SHARED_TOKEN must be set}"
BASE="https://api.filess.io"

filess_regions() {
    curl -sf "$BASE/v1/regions" \
        -H "Authorization: Bearer $TOKEN" \
        | jq -r '.data.regions[] | "\(.id)\t\(.name)"'
}

filess_create() {
    local name="$1" region="$2" motor="${3:-mysql-8.0.29}"
    curl -sf -X POST "$BASE/v1/instances" \
        -H "Authorization: Bearer $TOKEN" \
        -H "Content-Type: application/json" \
        -d "{\"identifier\":\"$name\",\"region\":\"$region\",\"motor\":\"$motor\"}"
}

filess_delete() {
    local id="$1"
    curl -sf -X DELETE "$BASE/v1/instances/$id" \
        -H "Authorization: Bearer $TOKEN"
}

case "$1" in
    regions)               filess_regions ;;
    create) filess_create  "$2" "$3" "$4" ;;
    delete) filess_delete  "$2" ;;
    *) echo "Usage: $0 regions|create <name> <region> [motor]|delete <id>"; exit 1 ;;
esac

Usage:

# Pick a region
./scripts/filess.sh regions
# → 4747ed15-34b7-4f41-a80b-387a6a907a1e  Spain

# Create
RESULT=$(./scripts/filess.sh create "pr-452" "4747ed15-34b7-4f41-a80b-387a6a907a1e")
DB_ID=$(echo $RESULT   | jq -r '.data.instance.id')
DB_HOST=$(echo $RESULT | jq -r '.data.instance.host')
DB_USER=$(echo $RESULT | jq -r '.data.instance.user')
DB_PASS=$(echo $RESULT | jq -r '.data.instance.password')
DB_NAME=$(echo $RESULT | jq -r '.data.instance.name')

# Delete
./scripts/filess.sh delete $DB_ID

When to Use Each API​

Shared API (api.filess.io) — for:​

• CI/CD pipelines: One database per PR, destroyed on merge.
• Prototypes: Spin up a database in 30 seconds to test an idea.
• Classroom / hackathon: Give each participant their own fresh database without managing accounts.
• Automated test suites: Integration tests that need a real database engine, not a mock.

Dedicated API (backend.filess.io) — for:​

• Production databases: Long-lived, monitored, backed up.
• Teams with RBAC: Organized under Organizations and Namespaces with granular permissions.
• Infrastructure-as-code: Provision databases as part of a Terraform or API-driven infrastructure workflow.
• Databases that need addons: Tailscale, firewall rules, PITR, SSH tunnels, PMM monitoring.

The Shared API is fast and frictionless by design. The Dedicated API gives you full control. Use the right one for the job.

Why Ephemeral Databases Beat Shared Staging​

The shared staging database pattern has real costs:

• Test flakiness: Tests pass or fail based on what a previous test run left behind, not on your code.
• Parallelism breaks: Two PRs can't simultaneously test a migration that adds and removes the same column.
• Cleanup debt: You need teardown scripts that are harder to maintain than the tests themselves.
• Data leakage: PII from database dumps living in a shared environment everyone on the team can access.

Ephemeral databases eliminate all of this. Each PR gets a clean slate. Migrations either work or they fail clearly. Parallel PR builds never interfere. The database is destroyed on merge, taking all test data with it.

The cost: a few seconds to provision and a few cents per PR on your Filess bill.

Get started with the Filess Shared API →

Then you hire a backend developer. You want them to see the production database metrics but not be able to delete anything. Then a contractor joins for three months — you want them to access the staging namespace only. Then your company gets acquired and the acquirer wants their DevOps team to manage infrastructure without touching billing.

Most database platforms weren't designed for this. You end up sharing root credentials via Slack DMs and hoping nobody does something irreversible.

Filess was designed from day one for teams that grow. Here's how the access model works.

The Three-Layer Model​

Access in Filess is organized in three layers:

Organization
└── Namespace (prod / staging / ci / team-a / team-b)
    └── Resources (databases, tunnels, hosting projects)

Organizations​

An Organization is the top-level billing and access unit. It represents a company, a team, or a project. All resources — databases, tunnels, hosting deployments — belong to an organization.

Key organization-level permissions:

• organization:view — Can see the organization exists.
• organization:update — Can edit organization settings.
• organization:billing:view — Can see billing and invoices.
• organization:invite:create — Can invite new members.
• organization:transfer_ownership — Can change who owns the organization.

Namespaces​

A Namespace is a logical partition within an organization. You might have:

• prod — Production databases, locked down. Only senior engineers can touch.
• staging — Staging databases. Full team access.
• ci — Ephemeral databases created and destroyed by CI pipelines.
• team-frontend — Backend databases that the frontend team needs read access to.

Namespaces let you implement environment isolation without separate accounts. The same team member can have write access in staging and read-only access in prod — from a single login.

Namespace-level permissions:

• namespace:create_in_organization — Can create new namespaces.
• namespace:view_in_organization — Can see a namespace.
• namespace:update_in_organization — Can rename/modify a namespace.
• namespace:delete_in_organization — Can delete a namespace and all its resources.

Resources​

Resources (databases, tunnels, SSH keys, IP allowlists, hosting projects) live inside namespaces. Each resource type has its own granular permission set.

Roles and Groups​

Rather than assigning permissions directly to users (which doesn't scale), Filess uses Roles and Groups.

Roles​

A Role is a named set of permissions. You create roles that match your team structure:

Example: db-reader

database:view_in_namespace
metrics:view_in_database
log:view_in_database
backup:view_in_database

Example: db-operator

database:view_in_namespace
database:update_in_namespace
metrics:view_in_database
log:view_in_database
backup:create_in_database
backup:view_in_database
backup:restore_in_database
maintenance_window:view_in_database
maintenance_window:create_in_database

Example: db-admin

database:create_in_namespace
database:view_in_namespace
database:update_in_namespace
database:delete_in_namespace
... (all database permissions)
backup:*
maintenance_window:*
alert_rule:*

Roles are defined at the organization level and can be applied to any namespace within that organization.

Groups​

A Group is a collection of users. Instead of assigning roles to individual users, you assign roles to groups, then add users to groups.

Why groups?

• When an employee joins, add them to the right group and they inherit all permissions immediately.
• When an employee leaves, remove them from the group and all access is revoked in one operation.
• When you onboard a contractor, create a time-limited group with restricted access.

Group: "backend-engineers"
  Members: alice, bob, charlie
  Namespaces: prod (role: db-operator), staging (role: db-admin)

Group: "frontend-engineers"
  Members: diana, erin
  Namespaces: staging (role: db-reader)

Group: "ci-bots"
  Members: github-actions-bot
  Namespaces: ci (role: db-admin)

The Full Permission Matrix​

Here's every permission in the system, organized by resource type:

Databases​

Backups​

Maintenance Windows​

Alert Rules​

Tunnels​

SSH Keys​

IP Allowlists​

Tailscale​

A Real Scenario: Fintech Startup​

You're building a fintech product. Here's how you'd structure Filess access:

Organization: acme-fintech

Namespaces:
  - prod       (Production databases)
  - staging    (Staging databases)
  - dev        (Development databases)
  - ci         (CI ephemeral databases)

Groups:
  - sre-team
      prod: db-admin
      staging: db-admin
      dev: db-admin
      ci: db-admin

  - backend-team
      prod: db-reader          ← Can see metrics, not modify
      staging: db-operator     ← Can manage backups, not delete
      dev: db-admin            ← Full control
      ci: db-admin

  - auditors
      prod: db-reader          ← Read-only, can see audit logs
      staging: (no access)
      dev: (no access)

  - github-actions
      ci: db-admin             ← Create/delete ephemeral DBs
      staging: db-operator     ← Run migrations on staging

A new backend engineer joins → add to backend-team. They immediately have the right access to every environment.

A compliance audit starts → add the auditor to auditors. They can see production metrics and logs without being able to modify anything.

A contractor leaves → remove from their group. All access revoked instantly, no password rotation needed.

Audit Logs​

Every administrative action is logged:

2026-04-01 09:14 UTC  alice@acme.com  created database "payments-prod"  namespace=prod
2026-04-01 09:45 UTC  alice@acme.com  created backup  database="payments-prod"
2026-04-02 14:22 UTC  bob@acme.com    updated alert rule "High CPU"  database="payments-prod"
2026-04-03 03:17 UTC  github-actions  created database "pr-452-test"  namespace=ci
2026-04-03 03:31 UTC  github-actions  deleted database "pr-452-test"  namespace=ci

The audit log is viewable by anyone with audit_log:view_in_organization permission. Export it for compliance purposes.

The Security Model Under the Hood​

Permission checks happen server-side on every API request. The middleware:

1. Extracts the authenticated user from the session or JWT token.
2. Determines the target resource and what action is being performed.
3. Looks up the user's group memberships.
4. For each group, checks if the group has a role assigned to the relevant namespace.
5. Checks if that role includes the required permission.
6. If any path returns true, the request proceeds. Otherwise, 403 Forbidden.

// From the codebase — every protected controller wraps this check:
if (!(await doesUserHavePermission(
  req.user,
  [ActionTypes.DATABASE_DELETE_IN_NAMESPACE],
  { organizationId: org.id, namespaceId: namespace.id }
))) {
  throw new FilessError(`You do not have permission to delete this database`, 403, true);
}

There's no way to bypass this check by passing different parameters in the request body — the resource ownership is always verified independently.

Starting Simple​

You don't have to use all of this on day one. When you're a solo developer:

• You have one organization.
• You have one namespace.
• You're the owner — you have all permissions.

You can add team members, create namespaces, define roles, and build groups incrementally as your team grows. The system scales with you rather than forcing you to over-engineer from the start.

What's Next​

The RBAC system is actively being extended. On the roadmap:

• Time-limited group memberships (perfect for contractors).
• Per-database access grants (in addition to per-namespace).
• API token scoping — limit a token to specific namespaces or operations.

Invite your team to Filess →

It works. For a while.

Then you hit the rate limit. Or the random subdomain changes every restart. Or you need to whitelist a specific IP and ngrok's plan doesn't cover it. Or your company's security policy blocks third-party tunneling software.

At Filess, we built our own managed tunnel infrastructure, and we're making it available as part of the platform. Here's the full technical breakdown of how it works.

The Architecture: SSH Reverse Tunnels​

The core mechanism is the classic SSH reverse tunnel (-R flag). When you connect, your machine dials outward through SSH to our tunnel server, and the server opens a port on its side that forwards all incoming traffic back to you through the open SSH connection.

Internet → Filess Tunnel Server → SSH connection → Your localhost:3000

No firewall rules to open. No router config. No public IP required. The only prerequisite is that your machine can make an outbound TCP connection on port 22222.

Here's the raw SSH command (we also have a CLI that wraps this):

ssh -R filess-tunnel-hostname:80:localhost:3000 \
    tunnel@tunnel.eu.filess.io \
    -p 22222 \
    -i ~/.ssh/id_rsa \
    -N

Your local port 3000 is now reachable at https://filess-tunnel-hostname.tunnel.eu.filess.io.

What Makes It Different from a Simple SSH -R​

Running your own reverse tunnel on a VPS is straightforward, but productionizing it is a different story. Here's what we built on top:

TLS Certificates — Automatic, Zero Config​

Every tunnel gets a unique hostname and a TLS certificate provisioned automatically via Let's Encrypt. No self-signed certs. No "your connection is not secure" warnings.

The certificate lifecycle is tracked in our database:

TunnelCertificate {
  status: pending | obtaining | valid | expired | failed
  domain: "abc123.tunnel.eu.filess.io"
  issuer: "Let's Encrypt"
  expiresAt: 2026-07-03T00:00:00Z
  obtainedAt: 2026-04-03T12:00:00Z
}

When a certificate nears expiration, our job scheduler picks it up and renews it. You never think about this.

Request Observability​

Every HTTP request that flows through your tunnel is logged:

GET /webhooks/stripe 200 47ms 1.2kb from 54.187.174.169
POST /api/callback  201 12ms 0.4kb from 185.93.54.20
GET /health         200  3ms  0.1kb from 10.0.0.1

The dashboard shows:

• Total requests in the last 24h
• Average response time
• Status code distribution (2xx, 4xx, 5xx)
• Bandwidth transferred
• Top client IPs

This is valuable during development. Instead of sprinkling console.log statements and squinting at terminal output, you see exactly what's hitting your tunnel in a clean UI.

Connection Events​

Every time a client connects or disconnects from the tunnel via SSH, the event is recorded with timestamp, client IP, and auth method used. If your tunnel shows unexpected connection attempts from unknown IPs, you'll know.

Webhook Delivery​

You can configure webhooks on your tunnel to get notified about connection events. Useful if you're building automation: start your dev server automatically when someone dials into the tunnel, for example.

Security Controls​

The default configuration is secure. But you can tighten it further:

IP Allowlists​

Two independent allowlists:

1. sshIPWhitelist: Controls who can connect to your tunnel via SSH. Lock it down to your office IP range.
2. ingressIPWhitelist: Controls who can send HTTP traffic through your tunnel. Lock it to Stripe's IP ranges if that's all you need.

{
  "sshIPWhitelist": ["203.0.113.42/32"],
  "ingressIPWhitelist": [
    "3.18.12.63/32",
    "3.130.192.231/32",
    "13.235.14.237/32"
  ]
}

Auth Methods​

Three modes:

• key: SSH key only. No passwords. Recommended.
• token: Temporary password (4-hour TTL, bcrypt-hashed in storage). Useful for CI runners where you can't manage SSH keys.
• both: Accept either. Flexible for team setups.

HTTPS-Only Mode​

Set httpsOnly: true and the tunnel server will reject plain HTTP connections, redirecting to HTTPS with a 301. Your webhook receiver always gets encrypted traffic.

Live Header Modifications​

This one is for power users. You can inject or modify HTTP headers on every request/response flowing through your tunnel, without touching your backend code.

{
  "liveHeaderModifications": [
    {
      "name": "X-Filess-Tunnel-ID",
      "value": "my-dev-tunnel",
      "type": "request"
    },
    {
      "name": "Access-Control-Allow-Origin",
      "value": "*",
      "type": "response"
    }
  ]
}

Use cases:

• Inject an Authorization header so your backend can verify requests came through the tunnel.
• Add CORS headers without modifying your app code.
• Stamp a X-Environment: development header to prevent your app from sending real emails when receiving tunneled requests.

CORS Preflight Passthrough​

If your frontend calls your tunneled backend directly, enable allowCorsPreflight: true. The tunnel server will handle OPTIONS requests automatically, which is useful when your local server doesn't respond to preflight properly.

The forwardToOtherHosts Flag​

By default, the tunnel only forwards to localhost. Enable forwardToOtherHosts: true and you can forward to any host reachable from your machine:

# Forward to a database in your local Docker network
ssh -R tunnel-hostname:5432:db.internal:5432 ...

This is how you can use a tunnel to give a colleague temporary read access to your local database without setting up a VPN.

Real Use Cases​

1. Receiving Webhooks During Local Development​

The canonical use case. Instead of deploying a staging environment every time you need to test a Stripe, GitHub, or Twilio webhook, you point the webhook URL at your tunnel and develop against real events locally.

# Start tunnel
filess tunnel start --port 3000 --name dev-webhooks

# Your webhook URL is now:
# https://abc123.tunnel.eu.filess.io/webhooks/stripe

Configure the URL once in Stripe's dashboard. Since the hostname is persistent (not random like ngrok's free tier), you don't need to update it every time you restart.

2. Sharing a Work-in-Progress UI with a Client​

You're building a feature. Your client wants to see it before it's deployed. Instead of pushing to staging, run:

filess tunnel start --port 5173 --name client-preview
# https://abc123.tunnel.eu.filess.io — share this with your client

The tunnel stays up as long as your dev server runs. The client sees live changes as you code.

3. Testing Mobile Apps Against a Local API​

Your React Native app needs to hit your API. You can't use localhost from a physical device. Point the app at your tunnel URL, and all traffic flows through to your local machine.

4. CI/CD Smoke Tests Against a Local Database​

Some integration tests need a real database. Instead of spinning up a cloud database for every test run, you keep a local database running and expose it through a tunnel for your CI pipeline to hit.

How Tunnels Fit Into Filess Organizations​

Tunnels are first-class resources in the Filess data model. They live inside a Namespace (within an Organization), which means:

• Multiple team members can have tunnel access via RBAC.
• Audit logs capture who created, modified, or deleted a tunnel.
• Billing is per-tunnel, tracked via Stripe subscriptions.
• Tunnels can be created, listed, and deleted via the REST API — automatable from scripts or CI.

# Create a tunnel via API
curl -X POST https://api.filess.io/v1/organizations/my-org/namespaces/dev/tunnels \
  -H "Authorization: Bearer $FILESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "webhook-receiver",
    "regionId": 1,
    "config": {
      "httpsOnly": true,
      "ingressIPWhitelist": ["3.18.12.63/32"]
    }
  }'

The Infrastructure Behind It​

Each region runs one or more Tunnel Endpoints — servers that handle SSH connections and proxy HTTP/HTTPS traffic. The endpoint schema:

TunnelEndpoint {
  domain:    "tunnel.eu.filess.io"
  sshHost:   "ssh.eu.filess.io"
  sshPort:   22222
  httpPort:  28080
  httpsPort: 28443
}

SSH runs on a non-standard port (22222) to avoid collisions with system SSH. The tunnel server manages the mapping from {hostname}.{domain} to the corresponding SSH connection.

When you create a tunnel via the API, the system:

1. Generates a random 16-character hex hostname.
2. Finds an active endpoint in the requested region.
3. Records the tunnel in the database.
4. Provisions a TLS certificate.
5. Returns the full tunnel URL.

The hostname is permanent for the lifetime of the tunnel. Delete the tunnel, the hostname is released.

Try It​

Tunnels are available to all Filess users. Head to the dashboard, create a namespace, and spin up your first tunnel in under a minute.

If you're building something where persistent, observable, secure tunnels would help — local development, webhook testing, client previews, or team demos — give it a shot.

Get started with Filess Tunnels →

You check your application logs. Everything seems fine. Your users aren't complaining. But deep down, you know you're flying blind. You have no idea if:

• Your queries are getting slower over time
• Your connection pool is about to hit the limit
• Your disk I/O is becoming a bottleneck
• Your replication lag is growing

In the old days, you'd cobble together a monitoring solution: install Prometheus, configure Grafana, write custom exporters, set up alerting rules. Weeks of work, and you'd still miss critical metrics.

Filess.io solves this by providing Percona Monitoring and Management (PMM) out of the box on all Dedicated Runtime databases.

The Pain: Building Your Own Monitoring Stack​

Setting up comprehensive database monitoring from scratch is a nightmare:

1. Install Prometheus: Set up the time-series database, configure retention, manage storage.
2. Deploy Exporters: Install mysqld_exporter, configure authentication, expose metrics endpoints.
3. Build Grafana Dashboards: Create dashboards from scratch, figure out which metrics matter, design visualizations.
4. Configure Alerting: Write PromQL queries, set thresholds, integrate with PagerDuty/Slack.
5. Maintain Everything: Keep exporters updated, fix broken dashboards, tune retention policies.

And even after all that work, you're still missing enterprise features like:

• Query Analytics to identify slow queries
• Database advisors that suggest optimizations
• Historical performance trends
• Security auditing capabilities

The Solution: Percona Monitoring and Management Built-In​

Percona Monitoring and Management (PMM) is an open-source platform for managing and monitoring MySQL, MariaDB, PostgreSQL, and MongoDB performance. It's the same tool used by companies like GitHub, Slack, and Etsy to monitor their databases.

On Filess.io, PMM is pre-configured and ready to use on every Dedicated Runtime database.

What You Get Out of the Box​

Query Analytics: See exactly which queries are slow, how often they run, and where they're spending time.

Performance Metrics: Real-time monitoring of connections, queries per second, replication lag, buffer pool usage, and more.

Database Advisors: Automated recommendations for query optimization, index creation, and configuration tuning.

Security Monitoring: Track authentication failures, privilege escalations, and suspicious activity.

Historical Data: Keep months of performance data for capacity planning and trend analysis.

Custom Dashboards: Pre-built dashboards for MySQL/MariaDB with the most important metrics at a glance.

How It Works in FILESS​

When you deploy a database on Filess.io Dedicated Runtime:

1. PMM Server is automatically deployed alongside your database cluster
2. PMM Client agents are installed on each database node
3. Metrics collection starts immediately - no configuration needed
4. Dashboards are pre-configured with best-practice visualizations

You don't need to:

• Install any software
• Configure exporters
• Write PromQL queries
• Build dashboards
• Set up alerting infrastructure

It just works.

Key Features of PMM in FILESS​

Query Analytics Dashboard​

Identify performance bottlenecks at a glance:

• Top slow queries: See which queries are taking the most time
• Query patterns: Group similar queries to find optimization opportunities
• Execution plans: Understand how queries are being executed
• Index recommendations: Get suggestions for missing indexes

Performance Monitoring​

Monitor all critical database metrics:

• Connection metrics: Active connections, connection errors, max connections
• Query performance: Queries per second, slow queries, query response times
• Resource usage: CPU, memory, disk I/O, network I/O
• InnoDB metrics: Buffer pool usage, read/write operations, lock waits
• Replication: Replication lag, replication status, binlog position

Database Advisors​

Get automated recommendations for:

• Query optimization: Identify queries that could benefit from indexes
• Configuration tuning: Suggestions for my.cnf optimizations
• Index analysis: Find missing or unused indexes
• Table optimization: Recommendations for table maintenance

Alerting​

Set up alerts for:

• High connection count
• Slow query rate
• Replication lag
• Disk space usage
• Memory pressure
• CPU utilization

Real-World Example: The Slow Query Mystery​

Imagine your Example App starts experiencing intermittent slowdowns. Users report pages taking 5+ seconds to load.

Without PMM: You'd spend hours digging through logs, running SHOW PROCESSLIST, trying to correlate application metrics with database performance. You might never find the root cause.

With PMM in FILESS:

1. Open the PMM dashboard (accessible from your Filess.io console)
2. Navigate to Query Analytics
3. See immediately that a specific SELECT query is taking 3+ seconds
4. Click on the query to see its execution plan
5. PMM Advisor suggests adding an index on customer_id
6. You add the index, and the problem is solved

All in under 10 minutes.

Why Percona Monitoring and Management?​

PMM is the industry standard for database monitoring because:

• Open Source: No vendor lock-in, fully auditable
• Enterprise-Grade: Used by companies managing thousands of databases
• Comprehensive: Covers all aspects of database performance
• Active Development: Regular updates with new features and improvements
• Community Support: Large community of users and contributors

Best Practices for Database Monitoring​

With PMM in FILESS, you can:

• Monitor proactively: Set up alerts before issues impact users
• Optimize continuously: Use Query Analytics to find slow queries regularly
• Plan capacity: Use historical data to predict when you'll need to scale
• Troubleshoot quickly: When issues arise, you have all the data you need
• Document performance: Use dashboards to communicate database health to stakeholders

Get Started Today​

Every Dedicated Runtime database on Filess.io includes Percona Monitoring and Management at no additional cost. No setup, no configuration, no maintenance.

Stop flying blind. Start monitoring like the pros.

Deploy a Database with Built-in PMM on Filess.io

You fire up TablePlus or DBeaver, but you hit a wall. The database is (rightfully) in a private network.

How do you get in?

Do you temporarily open port 3306 to the world? Dangerous. Do you deploy a VPN server just for this? Expensive.

The answer is an SSH Tunnel.

The Pain: The "Bastion Host" Maintenance​

Traditionally, to access a private database, you'd set up a "Jump Box" or "Bastion Host"—a tiny Linux server that sits on the edge of your network.

You'd have to:

1. Provision an EC2/Droplet.
2. Harden the OS (updates, fail2ban).
3. Manage SSH keys for every developer.
4. Run a command like:

   ssh -L 3306:private-db-host:3306 user@bastion-host
   

It's another server to pay for, patch, and worry about.

The Solution: Built-in SSH Gateways​

Filess.io gives you a managed Bastion Host for free with every database.

1. Go to your database Settings.
2. Add your Public SSH Key.
3. Copy the connection string.

Connecting with TablePlus / DBeaver​

You don't even need the command line. Most SQL clients support SSH tunneling natively.

1. Host: 127.0.0.1
2. Port: 3306
3. SSH Host: ssh.filess.io
4. SSH User: filess
5. SSH Key: Select your private key file.

Click Connect, and you're in. It feels like the database is running on your laptop, but all traffic is securely encrypted through the tunnel.

The Command Line Way​

If you prefer the terminal, it's just one command:

# Forward remote port 3306 to local port 3307
ssh -N -L 3307:db-endpoint:3306 filess@ssh.filess.io -i ~/.ssh/id_rsa

Now you can run your app locally against production data (carefully!):

DATABASE_URL="mysql://user:pass@127.0.0.1:3307/filess_example" npm start

Why It's Secure​

• Encrypted: All traffic is wrapped in SSH encryption.
• Key-Based: No passwords to brute force. Only holders of the private key can enter.
• No Public Ports: Your database port 3306 remains closed to the internet. The only entry point is the hardened SSH gateway.

Security Best Practices​

• Use Passphrases: Protect your local private SSH keys with a passphrase.
• Rotate Keys: Remove old keys from the Filess dashboard when developers leave.
• Read-Only Users: When debugging, log in with a read-only database user to avoid accidental DELETEs.

Get secure access without the hassle.

Start Your Secure Database on Filess.io

But wait—you're on public Wi-Fi. Your IP address changes every time you reconnect.

Do you open port 3306 to the world? No. Do you constantly update your firewall rules with your new IP? Tedious. Do you set up a complex OpenVPN server? Overkill.

Enter Filess.io + Tailscale.

The Pain: The "Dynamic IP" Dance​

If you want to access a private database securely from a remote location, you typically have two bad options:

1. The "Insecure" Way: Open the firewall to 0.0.0.0/0. Now hackers can brute-force your root password.
2. The "Annoying" Way: Log in to your cloud provider console, find your current IP (which changes hourly), add it to the whitelist, and repeat this every time you move.

And if you have a team of 10 developers? Good luck managing that whitelist.

The Solution: A Private Mesh Network​

With Filess.io's native Tailscale integration, your database joins your private network as if it were a device on your LAN.

1. Go to your database Settings.
2. Enable Tailscale.
3. Authenticate with your Tailscale account.

Your database gets a private IP (e.g., 100.x.y.z) that is only accessible to you and your team.

Connecting to Example App​

Now, from your laptop in the coffee shop:

# 1. Install Tailscale
brew install tailscale && sudo tailscale up

# 2. Connect securely (Magic!)
mysql -h 100.101.102.103 -u user -p filess_example

No ports opened to the internet. No firewall rules to update. Just secure, encrypted WireGuard® tunnels.

Why Developers Love This​

• Zero Config VPN: No certificates to manage, no ports to forward.
• Team Access: Grant access to your database using your existing identity provider (Google, Okta, GitHub).
• CI/CD Secure Access: Let your GitHub Actions runners connect to your DB securely without public exposure.

How It Works​

Tailscale builds a peer-to-peer mesh network. When you connect to your database:

1. Your laptop and the Filess database server exchange keys.
2. They establish a direct, encrypted connection (NAT traversal included).
3. Traffic flows directly between them, not through a central bottleneck.

Secure Your Workflow​

• Install Tailscale on your dev machine.
• Enable Tailscale on your Filess database.
• Close Public Ports: Disable public access entirely for maximum security.

Work from anywhere, securely.

Get a Private Database on Filess.io

Why? Because the Example App needs more RAM to handle the upcoming holiday traffic, and you have to manually resize the database server during the "low traffic" window.

You groggily open your laptop, SSH in, stop the service, resize the VM, restart the service, and pray it comes back up.

This is the "old way" of operations. It burns out engineers and risks human error.

Filess.io fixes this with automated Maintenance Windows.

The Pain: The Manual Upgrade Dance​

Upgrading a database manually is a high-stakes choreography:

1. Announce Downtime: Tell your users the site will be slow or down.
2. Snapshot: Take a backup (just in case).
3. Stop Traffic: Put the app in maintenance mode.
4. Perform Upgrade: apt-get upgrade or resize the instance.
5. Restart & Verify: Check logs, check connections.
6. Resume Traffic: Cross your fingers.

If anything goes wrong, you're debugging at 3 AM while losing money.

The Solution: Set It and Forget It​

With Filess.io, you define when you want changes to happen, and we handle the execution automatically.

1. Go to your database Maintenance tab.
2. Set your preferred window (e.g., Sunday at 02:00 UTC).
3. Request an upgrade (e.g., "Scale to 16GB RAM").

That's it.

Filess queues the change. When Sunday at 02:00 rolls around, our orchestration engine:

1. Spins up a new replica with the new specs.
2. Syncs data.
3. Performs a seamless failover (often with zero downtime).
4. Decommissions the old node.

You wake up on Sunday morning to a more powerful database, without having lifted a finger.

Real-World Example: The Holiday Rush​

Imagine our example-app is expecting 10x traffic for a flash sale next week.

Without Filess: You spend the weekend stressing about capacity planning and manual resizing.

With Filess: You click "Upgrade Plan" on Friday afternoon. You set the maintenance window for Saturday 01:00 AM. You go enjoy your weekend. By the time the sale starts, your database is ready.

Why It Matters​

• Predictability: Your team knows exactly when changes happen.
• Safety: Our automated workflows have rollback capabilities built-in.
• Sanity: No more 3 AM alarms for routine tasks.

Best Practices for Maintenance​

• Pick Low-Traffic Times: Use your analytics to find the quietest hour.
• Communicate: Even with zero-downtime upgrades, it's good practice to notify stakeholders.
• Test First: Apply changes to a staging environment first (easy to clone in Filess!).

Stop babysitting your database.

Automate Your Operations on Filess.io

But there's a problem. Your database port (3306) is open to the entire internet.

Any script kiddie with a port scanner can find your server, start brute-forcing passwords, or exploit a zero-day vulnerability.

You need to lock it down, now.

The Pain: The iptables Headache​

Securing a database server manually involves messing with Linux kernel firewall rules (iptables or ufw). It's a rite of passage for sysadmins, but a nightmare for developers.

To allow just your office IP and your app server, you have to SSH in and run commands like this:

# Install persistent rules so they survive a reboot
sudo apt install iptables-persistent

# Allow your office IP (hope you don't have a dynamic IP!)
sudo iptables -A INPUT -p tcp -s 79.148.34.11/32 --dport 3306 -j ACCEPT

# Allow your app server subnet
sudo iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 3306 -j ACCEPT

# BLOCK EVERYTHING ELSE (Don't lock yourself out of SSH!)
sudo iptables -A INPUT -p tcp --dport 3306 -j DROP

One wrong move, and you lock yourself out of your own server. Or worse, you think you blocked everyone, but you didn't.

The Solution: Filess.io Cloud Firewall​

With Filess.io, you don't touch the command line. You manage security where it belongs: in your dashboard.

1. Go to your database Settings.
2. Enable the Firewall addon.
3. Add your trusted IPs or CIDR blocks.

Done.

Our infrastructure instantly propagates these rules to the edge. Any connection attempt from an unauthorized IP is dropped before it even touches your database server.

Protecting the Example App​

For our example-app, we only want two things talking to the database:

1. Our App Server: 10.0.0.0/24 (Private Network)
2. Our Developer VPN: 79.148.34.11/32 (For debugging)

We add these two rules in Filess, and suddenly, the rest of the internet ceases to exist for our database.

Why It's Better Than iptables​

• Zero Risk of Lockout: You manage rules via our API/UI, not the server's network stack. You can always log in to Filess to fix a mistake.
• Instant Updates: Rules apply in seconds without restarting the database.
• DDOS Protection: By blocking traffic at the infrastructure level, we save your database CPU from having to process handshake attempts from attackers.

Security Checklist for Your Store​

• Enable Firewall: Whitelist only your app servers.
• Use SSL/TLS: Filess enforces this by default.
• Rotate Credentials: Use our API to rotate passwords regularly.

Don't leave your front door open.

Secure Your Database on Filess.io

Then, disaster strikes.

A developer, intending to clean up some test data, accidentally runs a DELETE command on the production database.

DELETE FROM sale WHERE id > 1000; -- Forgot the WHERE status = 'test' clause!

Poof. Hundreds of real customer orders just vanished. The phone starts ringing. The CEO is walking towards your desk.

In the old days, this would be the start of a very long, very bad night. But with Filess.io, it's just a 2-minute fix.

The Pain: The Manual Recovery Nightmare​

If you were managing your own database server (the "hard way"), recovering from this would be a panic-inducing ordeal.

First, you'd have to hope you configured binary logs correctly before the incident:

# Did you remember to set this?
log_bin = /var/log/mysql/mysql-bin
expire_logs_days = 10

Then, you'd have to scramble to find your last full backup and start the manual replay process:

1. Find the backup: ls -l /backups/mariadb/full_backup_*.sql
2. Restore it: mysql -u root -p < full_backup.sql (This takes time!)
3. Find the binlog position: Dig through files to find where the backup ended.
4. Replay logs: Carefully construct a mysqlbinlog command to replay everything up to the accident.

# One typo here and you corrupt data again
mysqlbinlog \
  --start-datetime="2025-11-21 14:00:00" \
  --stop-datetime="2025-11-21 17:32:58" \
  /var/log/mysql/mysql-bin.000123 | mysql -u root -p filess_example

It's slow, error-prone, and terrifying when money is on the line.

The Solution: Filess.io 1-Click Time Travel​

With Filess.io, we handle the complexity for you. We automatically take physical backups and stream transaction logs continuously.

To save our Black Friday sales, you simply:

1. Go to your database dashboard.
2. Click "Point-in-Time Recovery".
3. Select the exact time before the query ran (e.g., 17:32:58).

That's it.

Filess spins up a new database instance cloned from that exact second. Your original broken database stays there (just in case), and you get a fresh, perfect copy to verify.

Verifying the Fix​

Let's check our example-app data on the restored instance. We can run a quick query to see if our missing sales are back:

SELECT count(*) FROM sale WHERE id > 1000;
-- Result: 452 (They are back!)

Once verified, you just point your application to the new database endpoint. Crisis averted.

How It Works Under the Hood​

We don't use magic, just rock-solid engineering.

1. Physical Backups: We use tools like Percona XtraBackup or WAL-G to take non-blocking, physical snapshots of your disk. This is much faster than logical dumps (mysqldump).
2. Continuous Archiving: Every transaction (write, update, delete) is written to a Write-Ahead Log (WAL) or Binary Log. We stream these logs to secure object storage in real-time.
3. Automated Replay: When you request a restore, our orchestration engine spins up a fresh container, pulls the closest base backup, and automatically replays the logs up to your chosen timestamp.

You get the power of an enterprise DBA team, without hiring one.

Don't Wait for a Disaster​

The best time to set up a recovery plan is before you need it. With Filess.io, it's enabled by default on all Dedicated plans.

Ready to sleep better at night?

Deploy a Production-Ready Database on Filess.io