Skip to main content
Version: Develop

Core Concepts & Developer Workflow

This section describes the core concepts and workflow that developers should know to understand and consume the AWS RDS integration provided by Klutch.

Core Concepts​

RDS Instance

RDS instances are provisioned through Klutch using a minimal Kubernetes manifest requested by the developer. To request an RDS instance, developers specify two primary fields in the manifest:

  • serviceVersion
  • plan

ServiceBinding

A ServiceBinding connects an application to a provisioned rds instance by creating credentials and exposing them to the app.

What happens when developer creates a ServiceBinding:

  1. Klutch provisions a database user tied to the requested rds instance.

  2. The credentials and connection data are written into a Kubernetes Secret.

  3. Applications can consume the Secret (via env).

Backup

Klutch supports two backup patterns for RDS:

  • Manual backup — an on-demand backup taken at the time of request. Useful for ad-hoc backups before risky operations.

  • Scheduled backups — recurring backups using a schedule (daily/hourly), with configurable retention windows. Use these for regular protection and point-in-time recovery.

Restore

Developers can restore a database using one of two mutually exclusive restore modes:

  1. Backup restore Restore from a backup (manual or scheduled). You provide the backup ARN or backup name and Klutch creates a new instance from that backup.

  2. Point-in-time restore Restore to the latest restorable time or a specific timestamp within the retention period of scheduled backups.

Developer Workflow (summary)​

  1. Request a database
    Apply a database claim (e.g. a PostgreSQL claim) and specify the platform-provided serviceVersion and plan. This tells the platform which opinionated configuration to provision.

  2. Create a ServiceBinding
    Create a ServiceBinding that references the database claim. Klutch will create a database user for the binding and store credentials + connection information in a Kubernetes Secret.

  3. Consume the Secret in your app
    Reference the binding secret in your Deployment (for example with envFrom). Your application uses these values to connect to the DB.

  4. Backup the database
    Optionally create a manual backup or configure scheduled backups.

  5. Restore when needed
    Restore from a backup (manual or scheduled) by specifying the backup ARN/name, or perform a point-in-time recovery by providing the source database and timestamp.

Expected results​

  • A managed RDS instance is provisioned by the platform.
  • A Secret is created containing connection details for the database user (username, password, dbname, endpoint).
  • Backups are available per the configured policy; restores can be initiated from backups directly or point-in-time within the retention time.