How do I get an API token?

Create a project-scoped token from Security > API tokens in the DanubeData console, with permissions for the resources you manage. Supply it through DANUBEDATA_API_TOKEN. Keep it out of version control.

Can I create a VPS with provider 0.3.4?

VPS creation currently requires cpu_platform in the DanubeData API, but provider 0.3.4 does not expose that argument. The examples here use databases, caches and storage instead. Use the console or danube CLI for new VPS instances while this provider limitation remains.

Can I import existing resources?

The registered resources provide an import operation. Add the matching resource configuration and import its ID from the console or API, following the resource reference. Import attaches it to state; review the next plan before applying.

Will terraform plan estimate my bill?

The provider exposes monthly cost attributes returned by the API for some provisioned resources. These are computed values, not a forecast for resources that do not exist yet. Check the current pricing page when selecting a plan.

How should I manage multiple environments?

Use separate root modules or workspaces with separate state for each environment. Give each environment a project-scoped API token. Changing only the token does not isolate the resources already recorded in a state file.

How should I handle secrets and upgrades?

Keep API tokens in your environment or CI secret store. Mark sensitive outputs, and protect the state backend because sensitive values can still be stored there. Pin your provider version, commit its lockfile and review release notes and plans before upgrading.

Your infrastructure, reviewed as code.

Manage databases, caches and object storage with the DanubeData Terraform provider. Keep the configuration in Git, review a plan, then apply it to your infrastructure in Germany.

European-owned
German data centers
TLS encrypted

main.tf · provider setup

terraform {
  required_providers {
    danubedata = {
      source  = "AdrianSilaghi/danubedata"
      version = "= 0.3.4"
    }
  }
}

# Set DANUBEDATA_API_TOKEN in your environment.
provider "danubedata" {}

Provider 0.3.4. View on the Terraform Registry.

What customers say

“As a developer and cloud enthusiast, I’ve tried a lot of infrastructure platforms — but DanubeData genuinely stands out as one of the most intuitive, modern, and reliable cloud services I’ve used. From signup to deployment, everything feels thoughtfully designed and developer-centric. Deploying a VPS, cache, or database instance takes under a minute — and that’s not an exaggeration! Their intuitive dashboard and instant provisioning make launching new services effortless, even if you’re just getting started with cloud infrastructure”

Keoma WrightCEO/Founder at OpenWeb.co.za

“I’m running my new project’s backend on DanubeData and the experience has been smooth from day one—deployment is fast, the dashboard feels genuinely developer-friendly, and everything has been stable with no issues so far. Any time I had a question or hit a small blocker, the support was excellent: quick to respond, clear in explanations, and focused on getting me unblocked rather than sending me in circles. If you want EU-based infrastructure without the usual DevOps friction, DanubeData delivers.”

Cristian TorzsaCEO at InnovaSoftware SRL

“ruby/Sinatra invoicing application on a Docker container. Danube data was an obvious choice given its incredibly user friendly dashboard and automatic deployment directly from my GitHub repository via webhook. I've used many other platforms (Google, AWS, Azure), but Danube is the clear winner in terms of ease to configure, clear and honest pricing not to mention the excellent response time. Everything works perfectly so I hardly ever have to pull up the dashboard since I moved to Danube Data.”

Bo PereiraParis-Brest srl

Start with a configuration you can read.

Use the provider setup with one of these examples. The application stack combines the database, cache and bucket in one file.

Save this as main.tf. Supply a project-scoped API token through your environment, rather than a committed file.

Provider setup

terraform {
  required_providers {
    danubedata = {
      source  = "AdrianSilaghi/danubedata"
      version = "= 0.3.4"
    }
  }
}

# Set DANUBEDATA_API_TOKEN in your environment.
provider "danubedata" {}

Add to the provider configuration. resource_profile takes a plan slug, such as micro, rather than its dashboard display name.

Database

resource "danubedata_database" "main" {
  name             = "app-database"
  database_name    = "myapp"
  engine           = "postgresql"
  resource_profile = "micro"
  datacenter       = "fsn1"
}

output "database_endpoint" {
  value = danubedata_database.main.endpoint
}

Add a managed Redis cache. CPU and memory are derived from the plan; they are not writable arguments.

Cache

resource "danubedata_cache" "sessions" {
  name             = "app-sessions"
  cache_provider   = "redis"
  resource_profile = "micro"
  datacenter       = "fsn1"
}

output "cache_endpoint" {
  value = danubedata_cache.sessions.endpoint
}

Create a private, versioned S3-compatible bucket. Use the returned bucket name and endpoint in your application.

Object storage

resource "danubedata_storage_bucket" "uploads" {
  name               = "app-uploads"
  region             = "fsn1"
  versioning_enabled = true
  public_access      = false
}

output "storage_endpoint" {
  value = danubedata_storage_bucket.uploads.endpoint_url
}

output "bucket_name" {
  value = danubedata_storage_bucket.uploads.minio_bucket_name
}

Combine the database, cache and bucket in one configuration. These examples omit VPS creation because of the release limitation below.

Application stack

resource "danubedata_database" "main" {
  name             = "app-database"
  database_name    = "myapp"
  engine           = "postgresql"
  resource_profile = "micro"
  datacenter       = "fsn1"
}

output "database_endpoint" {
  value = danubedata_database.main.endpoint
}

resource "danubedata_cache" "sessions" {
  name             = "app-sessions"
  cache_provider   = "redis"
  resource_profile = "micro"
  datacenter       = "fsn1"
}

output "cache_endpoint" {
  value = danubedata_cache.sessions.endpoint
}

resource "danubedata_storage_bucket" "uploads" {
  name               = "app-uploads"
  region             = "fsn1"
  versioning_enabled = true
  public_access      = false
}

output "storage_endpoint" {
  value = danubedata_storage_bucket.uploads.endpoint_url
}

output "bucket_name" {
  value = danubedata_storage_bucket.uploads.minio_bucket_name
}

Read existing buckets and available image IDs without declaring new resources.

Data sources

data "danubedata_storage_buckets" "all" {}

output "bucket_names" {
  value = [for bucket in data.danubedata_storage_buckets.all.buckets : bucket.name]
}

data "danubedata_vps_images" "all" {}

output "available_images" {
  value = [for image in data.danubedata_vps_images.all.images : image.id]
}

Run from the directory containing your configuration. Plan and apply use the same reviewed change set.

Workflow

# Set a project-scoped DANUBEDATA_API_TOKEN first.
terraform init
terraform fmt
terraform validate
terraform plan -out=tfplan

# Review the saved plan before approving changes.
terraform show tfplan
terraform apply tfplan

VPS creation in 0.3.4

The API requires cpu_platform, which this provider release does not expose. For new VPS instances, use the console or the danube CLI. Explore VPS options while this limitation remains.

Choose a plan using its slug, and check current pricing before applying. A plan is a change preview, not a forecast of your bill.

The provider catalog, in one place.

Version 0.3.4 registers 15 resource types and 16 data sources. Open a group for the reference, including its arguments, returned values and import instructions.

Registered resources

Compute and hosting

Databases and caches

Storage and access

Snapshots

Data sources

Read resources and provider catalogs

Resource names describe the provider schema. Read the reference and release notes for each capability you intend to use.

Make infrastructure changes reviewable.

Use the same configuration in your terminal and CI. Keep the approval, state and credentials explicit.

Review the change before applying it
Commit HCL and the provider lockfile. Read the plan in a pull request or CI job, then approve the saved plan.
Reuse modules, separate state
Share resource definitions through modules. Give each environment its own state key and project-scoped API token.
Bring existing resources under management
Use terraform import with the resource ID and matching configuration. Review the next plan before making changes.
Protect credentials and state
Keep API tokens in environment variables or CI secrets. Sensitive outputs still live in state, so control access to your backend.

Documentation and source

Before your first apply.

Provider versions, state and existing resources.

Read the provider reference or DanubeData help for the details.

Create a project-scoped token from Security > API tokens in the DanubeData console, with permissions for the resources you manage. Supply it through DANUBEDATA_API_TOKEN. Keep it out of version control.
Link to this answer
VPS creation currently requires cpu_platform in the DanubeData API, but provider 0.3.4 does not expose that argument. The examples here use databases, caches and storage instead. Use the console or danube CLI for new VPS instances while this provider limitation remains.
Link to this answer
The registered resources provide an import operation. Add the matching resource configuration and import its ID from the console or API, following the resource reference. Import attaches it to state; review the next plan before applying.
Link to this answer
The provider exposes monthly cost attributes returned by the API for some provisioned resources. These are computed values, not a forecast for resources that do not exist yet. Check the current pricing page when selecting a plan.
Link to this answer
Use separate root modules or workspaces with separate state for each environment. Give each environment a project-scoped API token. Changing only the token does not isolate the resources already recorded in a state file.
Link to this answer
Keep API tokens in your environment or CI secret store. Mark sensitive outputs, and protect the state backend because sensitive values can still be stored there. Pin your provider version, commit its lockfile and review release notes and plans before upgrading.
Link to this answer

Build with managed EU services.

Put your next change in a plan.

Create an account, issue a scoped token and start with a small configuration you can review.

Create an account Read the provider docs

Start free

Compute

Storage

Managed apps

Caching

Databases

Messaging

Monitoring

DanubeData CLI

Automation & Agents

Tools

Developer docs

Learn

Support

Your infrastructure, reviewed as code.

What customers say

Start with a configuration you can read.

VPS creation in 0.3.4

The provider catalog, in one place.

Registered resources

Data sources

Make infrastructure changes reviewable.

Review the change before applying it

Reuse modules, separate state

Bring existing resources under management

Protect credentials and state

Documentation and source

Before your first apply.

Build with managed EU services.

Put your next change in a plan.