Account Limits

Understand resource limits and how to request increases for your projects.

What are Account Limits?

Account limits are restrictions on the number of resources you can create per project. They help:

• Prevent abuse and spam
• Ensure platform stability
• Manage resource allocation
• Control costs

Limits are per project, not per account.

Default Limits

Every new project on the Starter (default) tier starts with these limits. Higher account tiers raise these limits.

Viewing Your Limits

Check current limits and usage:

1. Open Account limits in the console sidebar, or go to console.danubedata.ro/account-limits
2. The band under the title shows the limit for each resource in the current project: databases, cache, VPS, Rapids containers and Storage Share instances
3. Each one says how many you use of how many you may have, and how many are left
4. Instance sizes, under it, lists the most one instance can have and which sizes you can choose

Usage Display

For each resource type, you'll see:

• Usage and limit: How many you're using, out of the most you may have ("3 of 5")
• What is left: "2 left", or "At the limit" once every one is used
• A meter that fills as you use the limit and changes colour as you near it:
  • 🟢 Green: Under 70% usage
  • 🟡 Amber: 70-90% usage
  • 🔴 Red: 90% usage and above

The words say the same as the colour, so you never need the colour to tell where you stand.

What Happens When You Hit a Limit?

When you reach a limit:

1. Creation Blocked: You cannot create more of that resource
2. Error Message: Clear message explaining the limit
3. Request Option: Link to request an increase
4. Existing Resources: Continue working normally

Example: If you have 3 VPS instances (the Starter limit) and try to create a 4th, you'll see:

You have reached your VPS instance limit. Request a limit increase at https://console.danubedata.ro/account-limits.

The API returns the same message in errors.account_limit, with HTTP status 422.

Requesting Limit Increases

Need more resources? Request an increase:

How to Request

1. Open Account limits in the console sidebar, or go to console.danubedata.ro/account-limits
2. Click Request an increase
3. Fill out the form:
   • Reason: What you need the resources for (at least 50 characters)
   • Instance limits: each one starts at your current limit, so raise only the ones you need. Only the limits you change are sent with your request
   • Larger instances: only if you need instances bigger than your limits allow. Here you can raise the most vCPU cores, memory and storage one instance can have, and ask for the sizes that are locked for you
4. Click Send request

You can have one open request at a time. While it waits for review, the page says so under the title with the date you sent it, and the button is hidden until it has been decided. We email the project owner the decision.

Requesting with an API token

A script or an AI agent that holds an API token can ask for a limit increase too, but it cannot raise your limits by asking. The request waits for the project owner, who approves or denies it in the console. That keeps a stolen token, or an agent that was told to do something you did not intend, from changing what your account is allowed to do.

1. Create the token with the account-limits:request permission. Any member's token can ask; only the owner can decide.
2. The agent sends the request. These are the fields of the form on the Account limits page: reason is required and must be at least 50 characters. Name at least one limit, or one resource profile, above what the project has now.

curl -X POST https://danubedata.ro/api/v1/account-limits/increase-requests \
  -H 'Authorization: Bearer YOUR_TOKEN_HERE' \
  -H 'Accept: application/json' \
  -H 'Idempotency-Key: 8a1c6f2e-7d3b-4c55-9d0e-2b6a1f0c9e11' \
  -d 'reason=Two more staging servers and a database for each staging environment.' \
  -d 'requested_vps_limit=5' \
  -d 'requested_database_limit=10'

The other fields are requested_cache_limit, requested_cpu_cores, requested_memory_gb, requested_storage_gb, requested_serverless_limit, requested_nextcloud_limit and requested_profiles. A limit that is not above the project's current one is left out of the request, so the owner reads only what would change. If nothing you named is above what the project has now, or you named nothing, the API answers 422 with "Ask for more than your current limits." under the fields you named (under requested_limits when you named none), and no approval is opened. Nothing changes when a request arrives. The API answers 202 with the approval, waiting for the owner:

{
  "success": true,
  "data": {
    "approval": {
      "id": "0199f0a0-3c1a-7f7e-9a51-0d6c2b8e4a10",
      "status": "pending",
      "terminal": false,
      "poll_after_ms": 30000,
      "action": "account_limit_increase",
      "summary": "Raise the database instance limit from 5 to 10 and the VPS instance limit from 3 to 5.",
      "requested_at": "2026-09-29T08:00:00+00:00",
      "expires_at": "2026-09-30T08:00:00+00:00",
      "decided_at": null,
      "failure_reason": null,
      "review_url": "https://console.danubedata.ro/approvals/0199f0a0-3c1a-7f7e-9a51-0d6c2b8e4a10"
    }
  },
  "error": null,
  "meta": {}
}

3. The owner gets an email with the subject "Your API token asked to raise your account limits". It shows what was asked, the token, who it belongs to and the time. The IP address and the browser are labelled as reported by the request, because the caller sets them. The reason is the caller's own words, shortened, with any web or email address made unclickable (example[.]com). Its button opens the request in the console. The email has no link that approves on a click.
4. The owner opens the request from the email, or from the Account limits page, which points to it while one is waiting (the Approvals list is in the command palette), then approves or denies it. Approving asks them to confirm it is them: with a passkey, their password or an authenticator code, or with a code we email to an account that has no password.
5. The agent asks GET /api/v1/approvals/{id} until terminal is true, and waits at least poll_after_ms between asks.

A few rules to build around:

• One at a time. While an approval is waiting, or a limit increase request is already open for the project, a new request gets 409. The error code is approval.already_pending (with the waiting approval's approval_id) or account_limits.request_pending.
• Retries are safe when you send an Idempotency-Key: the same key returns the same approval instead of opening a second one.
• At most 5 approvals an hour can be opened for a project (the one named by X-Team-Id, or the one the token is scoped to), and 5 an hour by one token however many projects it reaches. Past that the API answers 429. A request that is refused or invalid does not count, and neither does a retry with the same Idempotency-Key.
• Deleting the token cancels what it asked. If the token is deleted, or the person it belongs to leaves the project, while a request waits, approving it ends as failed and nothing is filed.
• Only the owner decides, and only in the console. A token can open a request but cannot view, approve or deny it in the console, not even the owner's own token. The token reads the status of its request with GET /api/v1/approvals/{id}.
• It all lands in the Activity Log as approval.requested, approval.approved, approval.denied and approval.expired, with the token that asked.
• The caller's words do not stay for ever. The reason, the IP address and the browser of a request are removed 90 days after it was decided or expired. What was asked, the decision and who made it stay on the approval. Its Activity Log entries follow the Activity Log's own retention.

Justification Tips

Be specific and provide context:

Good Examples:

• "Expanding production deployment from 5 to 15 microservices"
• "Onboarding 3 new major clients, need 20 database instances"
• "Scaling read operations, need 8 database replicas"

Poor Examples:

• "Need more"
• "Testing"
• "Just in case"

Review Process

1. Submission: Request submitted immediately (for a request made with an API token, once the owner approves it)
2. Review: Our team reviews within 24-48 hours
3. Decision: Approved or denied with feedback
4. Notification: Email notification of decision
5. Applied: If approved, new limit applied immediately

Approval Factors

We consider:

• Account Age: Established accounts get priority
• Payment History: Good standing helps
• Current Usage: Are you using existing resources?
• Justification: Clear business need
• Request Size: Reasonable increases approved faster
• Resource Type: Some resources easier to increase

Common Approval Scenarios

Usually Approved:

• 2-3x current limit
• Clear business justification
• Good account standing
• Reasonable resource request

May Require Discussion:

• 5x+ current limit
• Very new accounts
• Payment issues
• Vague justification

Typically Denied:

• Speculative "just in case" requests
• No clear justification
• Recent account with no usage
• Outstanding payment issues

Managing Within Limits

Can't wait for approval? Optimize your usage:

VPS Instances

Consolidate:

• Use containers instead of separate VPS
• Run multiple services per VPS
• Use orchestration (Docker, Kubernetes)

Clean Up:

• Delete unused development/test instances
• Remove old staging environments
• Archive old projects

Database Instances

Optimize:

• Use one database with multiple schemas
• Share databases across applications
• Use read replicas instead of separate instances

Clean Up:

• Remove unused test databases
• Archive old project databases
• Consolidate similar databases

Cache Instances

Consolidate:

• Use Redis databases (0-15 per instance)
• Share cache instance across applications
• Use key prefixes for separation

Clean Up:

• Remove development cache instances
• Delete unused staging caches

Firewalls

Reuse:

• One firewall can attach to multiple instances
• Create shared firewalls for common use cases
• Use templates for similar configurations

Clean Up:

• Delete unused firewalls
• Consolidate similar firewalls

Snapshots

Manage:

• Delete old snapshots regularly
• Keep only necessary recovery points
• Use automated cleanup policies

Limit Increase Pricing

Limit increases are free. There's no charge for raising your limits.

You only pay for the resources you actually use, not for the limit itself.

Example:

• Default limit: 10 databases
• Increased to: 50 databases
• You create: 12 databases
• You pay for: 12 databases only

Project-Specific Limits

Limits are per project, so:

• Each project has independent limits
• Creating a new project gives you a fresh set of limits
• Use multiple projects to separate resources

Example:

• Production Project: 10/10 VPS used
• Development Project: 2/10 VPS used
• Total Across Projects: 12 VPS possible

Higher Tiers

Beyond the Starter defaults, accounts can be moved to the Professional or Enterprise tier, which raise your resource limits significantly. For reference, the Enterprise tier allows up to:

• 50 VPS instances
• 100 database instances
• 100 cache instances
• Higher per-database replica limits than the Starter default of 5

If you need limits at this scale, request an increase from the Account limits page or contact support through the dashboard to discuss the right tier for your account.

Temporary Limit Increases

Need a short-term increase?

Scenarios

• Load testing
• Product launch
• Seasonal traffic spike
• Migration from another provider

Request Process

1. Submit increase request as normal
2. In justification, mention it's temporary
3. Specify the duration needed
4. We can approve temporary increases faster

Post-Event

• Reduce resources after event
• Limits may be adjusted back down
• Contact support to discuss

Frequently Asked Questions

Why do limits exist?

Limits prevent:

• Accidental runaway resource creation
• Cost overruns
• Platform abuse
• Resource exhaustion

They ensure platform reliability for all users.

Can I get instant limit increases?

For security and stability, all increases require review.

What if I need resources urgently?

1. Optimize current usage first
2. Submit request with "urgent" in justification
3. Contact support via dashboard

Do limits reset?

No. Once increased, limits stay at the higher level unless:

• You request a decrease
• Temporary increase expires
• Account issues require adjustment

Can I decrease my limits?

Yes, contact support. However, there's no benefit since limits are free.

Do limits apply to snapshots?

Yes, 50 snapshots per instance (VPS, database, or cache). Total across all instances in a project can be much higher.

Are there bandwidth limits?

No bandwidth limits — egress traffic is pooled per team, with 20 TB included per VPS instance, 1 TB per storage bucket, and 1 TB per serverless container. Overage is billed at EUR 1.00/TB.

Are there API rate limits?

Yes. Limits scale with your account tier — starting at 2,000 requests per hour and rising to 100,000 per hour on higher tiers.

See API Rate Limits for details.

Best Practices

Plan Ahead

• Request increases before you need them
• Allow 24-48 hours for review
• Don't wait until you're blocked

Be Realistic

• Request what you need, not arbitrary numbers
• Easier to get multiple small increases than one huge increase
• Show gradual growth

Clean Up Regularly

• Delete unused resources weekly
• Review usage monthly
• Keep within 70% of limits when possible

Use Multiple Projects

• Separate production and development
• Independent limits per project
• Better organization

Document Growth

• Track resource usage over time
• Forecast future needs
• Use data to justify increases

Monitoring Your Limits

The Account limits page shows live usage against each limit with a meter that turns amber and then red as you near a cap, so you can see when you're approaching one and request an increase before you're blocked.

Next Steps

• View Your Current Limits
• Project Management
• Billing Overview
• Contact Support

Need higher limits? Request an increase now.