Cloud hosting FAQ

DanubeData provides cloud infrastructure and managed services from one console. You can deploy Linux VPS instances, managed databases and caches, S3-compatible object storage, RabbitMQ queues, serverless containers, static sites and managed apps. Choose a service based on how much of the operating system and application stack you want to manage yourself.

DanubeData is a fit when you want EU-hosted infrastructure with a single place to manage compute, databases, caches and storage. Use a VPS for control over the operating system, or a managed service to reduce routine infrastructure work. Compare the current plans, supported features and service terms against your application requirements before choosing a provider.

Create an account, verify your email and create a project. Add a payment method when required, choose a service and review its plan, location and estimated cost before deploying. The getting-started guide walks through the console and the settings you need for your first resource.

DanubeData offers infrastructure in Falkenstein, Germany, under the fsn1 location. Check the location shown when creating your service. EU hosting can support your data residency requirements, but your compliance obligations also depend on your application, how you process personal data and the applicable service agreements.

Choose a VPS when you need root access and control over the operating system. Choose a managed database, cache or app when you want the service without managing its host. Rapids suits containerized web applications and APIs; Static Sites serves prebuilt HTML, CSS and JavaScript. Match the service to your runtime, storage and operational requirements.

FKS, the Fluid Kubernetes Service, is presented as coming soon and is not generally available yet. The planned service combines a managed control plane with configurable worker pools and standard Kubernetes tooling. Check the Kubernetes solution page for its published scope; do not plan a production deployment around an unannounced launch date.

Resource charges are based on the service and plan you choose, with usage collected throughout the month and billed on a monthly invoice. Instances continue to incur charges while stopped because their resources remain allocated. Review the current pricing and your project usage for compute, storage, backups and traffic before estimating a total.

You can add credit or debit cards through Stripe in Billing, under Payment Methods. Stripe processes the card details; DanubeData does not store the full card number or security code. Keep a valid primary payment method and check your billing settings for any other payment arrangements available to your project.

VAT depends on your billing country, customer status and validated tax details. Add your billing address and, if applicable, your VAT number in the billing settings before invoicing. A VAT number does not automatically make every invoice tax-free; reverse charge applies only when the transaction qualifies. Your invoice shows the tax treatment applied.

Monthly invoices are generated on the first day of the month for the previous month's usage. The scheduled automatic card collection runs on the second day, after a review window. View the invoice and payment status in Billing, and check its due date if your project has separate payment terms.

Free plans and promotional credits are specific to the service and the current offer. Check the pricing page for available plans and Billing for any credits granted to your project, including their expiry date. Credits reduce eligible invoice charges; they do not stop paid resources from accruing usage when the credit runs out.

No. Stopped VPS, cache and database instances remain billable at their full rate until you delete them. Back up any data you need before deleting a resource, then review separately retained backups, snapshots, volumes and other resources for ongoing charges. Deletion stops future instance usage charges; it does not remove charges already accrued.

VPS plans combine virtual CPUs, RAM and local NVMe storage, with shared and dedicated CPU options. Available sizes and CPU platforms are shown in the current plan catalog and creation form. Choose based on your workload, then check CPU, memory and disk usage in the console to see whether you need a different plan.

The VPS image catalog includes Ubuntu, Debian, AlmaLinux, Rocky Linux, Fedora and Alpine. The creation form shows the versions currently offered for each distribution. You can supply cloud-init configuration during setup; choose an image that supports the software and maintenance lifecycle your application needs.

Yes. You get root access to your Linux VPS and can install software and manage its configuration. Configure an SSH key or a root password during creation, and restrict SSH access with firewall rules. You are responsible for the guest operating system, application updates and any software you install.

Yes. Open your VPS and use Resize to choose an available profile. A resize can require the server to stop and restart, so schedule an interruption and take a backup first. Disk size and existing data can restrict smaller profiles; check the available choices before planning a downgrade.

VPS instances use dual-stack networking by default, with IPv4-only and IPv6-only choices available during creation. Private networks connect selected resources without using their public addresses. Use firewall rules to allow the sources and ports your application needs, and check the plan for its traffic allowance and network limits.

A Floating IP reserves an IPv4 or IPv6 address independently of your VPS. An additional address can move between compatible VPSs in the same project and network zone, with guest setup and a planned interruption. A primary reservation stays linked until its VPS is deleted and cleanup completes. Floating IPs are in beta and do not provide automatic failover. Check the console for availability and pricing.

Yes. Additional VPS volumes let you grow storage separately from the compute plan. Choose the target VPS when creating the volume, then identify, format and mount the new empty data disk inside Linux. Extra volumes have separate storage charges and different performance characteristics from the local NVMe root disk.

Non-destructive detach and moving an existing volume to another VPS are not supported. Plan a data copy to storage on the destination server instead. Verify the copy before deleting the old volume, because deletion permanently removes its data. Stopping the VPS does not delete its volume or stop allocated-storage charges.

Private Networks connect selected VPS instances on a private IP range you choose. Managed databases, caches and queues already have their own private endpoints, listed under Networking; they do not need a VPS private network for that access. Private Networks are being rolled out, so check whether the feature is enabled for your project.

Network Peering connects the internal networks of two projects owned by the same account. It opens connectivity in both directions; the firewalls on individual resources still apply. Use the exact internal endpoint of the destination service. Peering is separate from attaching VPS instances to a Private Network and does not support projects owned by different users.

Check that the VPS is running, you are using its current public address and your firewall permits SSH from your source IP. Confirm the username and SSH key selected during setup. If the network connection works but login fails, use verbose SSH output and the console recovery options to inspect the guest configuration.

DanubeData offers Redis, Valkey and Dragonfly as managed in-memory services. Redis and Valkey suit many applications using Redis commands; Dragonfly offers a multithreaded alternative. Check your application's required commands, client libraries, persistence and replication needs against the selected engine before migrating. The creation form lists the available versions.

Replicas are optional on supported managed cache instances; they are not included with every cache by default. Replication and failover behavior depend on the engine and deployment type. Review the options shown for your instance, allow for replica costs and configure client retries. A replica does not replace a backup or guarantee that every recent write survives a failure.

Redis and Valkey support RDB snapshots and append-only file (AOF) persistence, configured through supported settings. Dragonfly uses periodic snapshots rather than Redis-style AOF. Choose settings for the amount of recent data you can afford to lose, and keep backups when the data cannot be rebuilt from another source.

The configured eviction policy determines whether the cache removes keys or rejects writes when it reaches its memory limit. Supported policies depend on the engine; common choices use key age, access frequency or expiry times. Review the available parameter settings, add expiry times where appropriate and monitor memory use before the instance fills up.

The cache dashboard shows resource and engine metrics such as memory use, connected clients, operations, cache hits and misses, and evicted keys. Replication metrics are available where the instance supports them. Use the time range and metrics available for your instance to investigate capacity, connection or performance problems.

Managed Redis suits application caching, sessions, counters and other workloads built around Redis commands. Configure memory limits, eviction and persistence for the role it plays in your application. A rebuildable cache and a queue or session store have different recovery needs, so check the consequences of lost or evicted keys before deployment.

Valkey supports Redis-compatible clients and many applications using Redis commands. Check the commands, modules and behavior your application depends on before switching engines, and test against the offered version. Redis and Valkey share the persistence options covered in the cache persistence guide, but a compatibility claim should be checked against your actual workload.

Dragonfly is a multithreaded in-memory service with Redis protocol compatibility. It uses periodic snapshots for persistence rather than Redis-style append-only files. Test required commands and client behavior before migrating, and choose the available memory, persistence and replica settings for your workload instead of assuming every Redis feature behaves identically.

DanubeData offers managed PostgreSQL, MySQL and MariaDB. The creation form lists the versions and plans currently available. Choose the engine your application supports, then review its connection settings, extensions or plugins, backup options and replica support. Managed database access does not mean unrestricted control over the underlying host.

Managed databases have scheduled backups, with recovery options and retention that depend on the engine and backup policy. PostgreSQL also supports point-in-time recovery within the available recovery window; MySQL and MariaDB restore from backups. Check the Backups tab for successful backups and restore options, and test a restore before relying on it for recovery.

Supported managed databases let you add replicas to handle read traffic and improve resilience. Replica options, endpoints, promotion and failover behavior vary by engine and deployment type. Send writes to the primary and use the appropriate endpoint for reads. Replication can lag, so applications must allow for reads that do not yet include the latest write.

Connection limits depend on the database engine, configuration and resources available to the instance. Check its connection settings and metrics before increasing the limit. Managed PostgreSQL supports a PgBouncer connection pooler; pooling can help applications reuse connections instead of opening a new server connection for every request.

Yes. Parameter groups let you apply supported engine settings to one or more databases. The available parameters and valid values depend on the engine and version. Review every instance using the group before changing it, and plan for a restart when a setting cannot be applied while the database is running.

Create a compatible managed database, export your existing data with the engine's backup tools and import it using the new connection details. Test application queries, users and extensions before switching traffic. For large or busy databases, plan the transfer and cutover with support; the right approach depends on engine compatibility, access to the source and acceptable downtime.

Choose PostgreSQL when your application needs its SQL behavior, supported extensions and data types. DanubeData provides managed PostgreSQL with backup and recovery options, a connection pooler and browser-based SQL Studio. Check the current engine version, extensions, connection settings and recovery window before moving an existing application.

Yes, if the application and database are compatible with the MySQL version you select. Check SQL modes, character sets, users and any engine-specific requirements before importing a dump. Test the restored data and application queries, then plan the final cutover around writes still arriving at the old database.

Use the engine your application officially supports and test its required features. MariaDB and MySQL share many concepts, but their versions, plugins, SQL behavior and replication features differ. Check the managed engine options before migrating; a MySQL-compatible connection library does not prove that every schema or query can move unchanged.

SQL Studio is available for managed PostgreSQL databases, with a table editor, SQL editor and schema tools inside the console. It is not available for MySQL, MariaDB or demo accounts. Open the PostgreSQL instance and select SQL Studio to browse its databases without installing a separate database client.

No. SQL Studio opens in read-only mode. After enabling Write mode, table edits are staged until you choose Commit; you can discard them first. A commit applies its staged changes in one database transaction. SQL editor statements run separately, so review the selected database and the statement before executing a write.

Configure your database client to require TLS using the connection settings for your engine. Managed PostgreSQL also has a Require TLS option on the Connectivity tab to refuse unencrypted connections. Encrypting a network connection is separate from encrypting stored data; review the platform security guide if you also need encryption at rest.

Object storage keeps files as objects inside buckets and exposes them through an S3-compatible API. Use it for application uploads, media, downloads and backups. It is different from a VPS disk or a mounted block volume: your application accesses objects by key through an S3 client or HTTPS request.

Object storage costs depend on the current bucket plan, stored data and billable outbound traffic. Check the pricing page for included allowances and overage rates, then review usage in the console. Previous object versions also consume storage, so versioning and retention settings can affect your total even when the visible file list is small.

Copy the S3 endpoint and bucket name from the console, then configure your client with an access key ID and secret key that can reach that bucket. You can use tools such as the AWS CLI, rclone or an AWS SDK with a custom endpoint. Keep secrets out of source code and use the permissions your application needs.

Object Storage supports features including versioning, CORS, lifecycle rules, access policies, bucket quotas and server-side encryption. Object Lock is available when enabled at bucket creation. S3 compatibility does not mean every AWS S3 operation is supported; check the supported-actions guide for the requests your application uses.

When bucket versioning is enabled, uploading the same object key creates a new version, and a normal delete creates a delete marker. Earlier versions can help recover overwritten or deleted files. All retained versions count toward storage usage; suspending versioning does not remove them. Use lifecycle rules or delete unwanted versions to reclaim space.

Object Storage uses HTTPS for transfers and supports AES-256 server-side encryption. New buckets enable SSE-S3 by default unless you turn it off. Encryption applies to objects written while it is enabled, so older objects are not encrypted retroactively. Check the bucket settings, or encrypt files before upload if you need to control the encryption yourself.

An S3 credential contains an access key ID and a secret access key. Create a separate key for each application and choose access to all buckets, selected buckets with specific permissions, or access granted only by bucket policy. Store the secret securely and replace or revoke keys when access changes. Never put secret keys in public code or browser JavaScript.

Yes. You can enable public read access when a bucket is intended to serve public assets such as images or downloads. Anyone with an accessible object URL can then read that content without S3 credentials. Keep private data in a private bucket, and use signed URLs when you need temporary access to a specific object.

Check your project limits and the bucket's configured size quota before planning an upload. Bucket quotas can limit stored data, while S3 upload limits and multipart requirements apply to individual objects. Include retained versions in your capacity estimate, and monitor usage so a full bucket does not interrupt uploads.

Lifecycle rules expire objects automatically after the age you configure, optionally for a matching key prefix. Use them to clear temporary uploads, logs or old backups. Versioned buckets need rules for non-current versions as well as current objects. Review retention requirements and Object Lock settings before enabling automatic deletion.

Yes. Create an SFTP user from the bucket's SFTP section and associate it with an S3 access key that has permission to that bucket. Use the host, port and exact username shown in the console; the password is the associated access key's secret. Rotating or revoking that key also affects SFTP access.

Yes. Use an S3 transfer tool such as rclone to copy objects between the source and your DanubeData bucket. Configure each provider's endpoint and credentials, test a small transfer and verify the results before changing application traffic. Check versioning, metadata and policy requirements separately, because copying current objects is not the same as migrating every bucket setting.

Object Lock protects retained object versions. An authorized team-wide key can bypass governance retention; compliance retention cannot be shortened or bypassed, even by the bucket owner. Enable Object Lock at bucket creation because it cannot be added later. Coordinate retention with your backup software, and allow for locked versions continuing to consume storage.

Check the endpoint, bucket name, access key and signing configuration in your S3 client. Then confirm that the key or bucket policy grants the operation you are attempting; read access does not allow uploads or deletion. Use the signature requirements and supported-actions guides to distinguish authentication problems from unsupported or unauthorized requests.

Rapids runs containerized web applications and APIs without requiring you to manage a VPS operating system. Deploy a Docker image, build from a Git repository or upload supported source code. Your application must listen on its configured port and handle requests as a container; choose a VPS when you need control of the host.

Yes. Rapids supports Git deployments with buildpacks that detect supported application stacks, or a Dockerfile when you need to control the image build. Configure the repository, branch and build settings, then review build logs. A webhook can trigger builds on pushes to the selected branch.

With minimum replicas set to zero, Rapids can stop idle container instances and start them again when traffic returns. The first request then waits for startup, which depends on the image, application and attached storage. Keep a minimum replica running when startup delay is unacceptable, and allow for its compute cost.

Files written only to the container's own filesystem do not survive an instance stopping. Attach a persistent volume for data that must survive deployments, restarts and scale to zero, or use object storage for files shared between containers. A Rapids volume belongs to one container and is a single copy on one server.

No. Deleting a Rapids container deletes its attached volume and that volume's backups. Export any data you need before deletion and verify the copy independently. A volume remains billable while its container is stopped or scaled to zero, and deleting files inside it does not reduce its allocated size.

Yes. Add the domain to the container, publish the ownership-verification record and point DNS to the target shown in the console. TLS provisioning follows successful verification and routing. Check the separate verification, DNS and certificate statuses when a custom domain is not ready; copying only the TXT record does not route website traffic.

Rapids endpoints are publicly reachable by default. Implement authentication in your application when requests should be restricted; the platform forwards request headers so you can validate tokens or another supported application-level method. A DanubeData management API token is separate from the authentication your own application accepts.

Read the current egress IP list linked from the Rapids egress guide rather than copying addresses into a permanent configuration. These public addresses are shared by customers, so an IP allowlist does not identify your container by itself. Authenticate outbound calls with a credential your destination verifies when access must be restricted to your application.

A failed new revision can leave the previous healthy revision serving traffic. Check the deployment status, image-pull details, startup configuration and logs before retrying. A successful image build does not prove the application became ready. Fix the reported cause instead of repeatedly deploying the same configuration.

Where Rapids Runs is enabled, start a one-off command from the container's Runs tab or API. It runs separately from the replicas serving requests and reports its status, exit code and output. The feature is in preview; check account availability and the run guide before depending on it for a deployment workflow.

Yes, when the build produces static HTML, CSS, JavaScript and assets. Deploy the generated output directory for a single-page app, documentation site, portfolio or marketing page. Static Sites does not run a persistent application server; use Rapids for a runtime that must execute code on incoming requests.

Connect a supported Git repository and configure its build command and output directory, or upload prebuilt site files. The danube CLI also supports a deployment workflow for local and CI use. Review the resulting build and deployment status before updating production DNS.

Yes. Add the domain, verify ownership with the TXT record shown in the console and configure the routing record. Subdomains can use CNAME; root domains need a DNS-provider option such as ALIAS, ANAME or CNAME flattening. The domain guide explains certificate provisioning and the status shown while DNS is still propagating.

A failed build does not replace the previous successful deployment. Open the build logs to inspect the error, then correct the repository or build settings and retry. Deployment history lets you return to a previous deployment. Keep your source and configuration in version control so you can reproduce a working build.

Static Sites supports site-wide HTTP Basic Auth for password protection. Use it for a staging site or a preview that should not be publicly browsable. The protection applies to the whole site rather than selected pages; application-specific accounts or permissions require your own application logic and a suitable runtime.

Yes. An AI-generated site can be deployed when it produces working static files or a supported static build. Preview the result, replace placeholder content and check links, forms and mobile behavior before publishing. Code that needs a backend must connect to a separate API or run on a service such as Rapids.

The managed app catalog includes WordPress, Ghost and n8n, with the currently offered versions and plans shown in the console. Choose an app for its intended workflow instead of managing its full stack on a VPS. Storage Share is the separate managed Nextcloud offering for file sync and sharing.

Marketplace Apps install a software stack on a VPS during first boot using cloud-init. You retain root access and manage its operating system, software and updates. Managed Apps are separate application instances with supported console management actions. Check the marketplace entry for operating-system compatibility, resource requirements and setup instructions before deploying.

Managed WordPress includes the WordPress application, its database and object cache, persistent storage, an HTTPS address and management through the DanubeData console. You manage website content and WordPress administration. Select a plan for the site's resource needs and review backup, domain and update options before launch.

Yes. Use your WordPress admin account to manage plugins and themes. Review their compatibility and resource requirements, and take a recovery point before a change that could affect the site. The managed app's database runs alongside the application and is not exposed as a separately accessible managed database.

Managed n8n provides the workflow application with PostgreSQL for workflow data and Redis for queue-based execution. You build workflows, configure credentials and connect the external services they use. Review the selected profile's resources and parallel-workflow allowance when planning automation workloads.

The managed app guide supports installing community nodes through n8n's interface. Review a node's trustworthiness, compatibility and access to workflow credentials before installing it. Check application logs and resource use if a workflow fails, and keep your own record of the external services and permissions each workflow depends on.

Managed Ghost provides the publishing application, its MySQL database, persistent storage, an HTTPS address and custom-domain support. You manage the publication and its staff accounts in Ghost. Email is a separate setup step: connect a suitable SMTP provider for supported transactional messages instead of assuming email sending is configured automatically.

Open the Ghost instance's Email (SMTP) tab and connect your own provider using its hostname, credentials, supported encrypted port and verified sender. Saving and applying settings restarts Ghost, causing a brief interruption. Send the test email after the settings apply, and check delivery separately; provider acceptance does not prove an email reached the inbox.

Create the admin account in the application's setup screen as soon as the instance is running. For these apps, you choose the password and DanubeData does not hold a copy that the console can reveal or reset. Use the application's account-recovery process, and configure any email service it needs before relying on password-reset mail.

Yes. Add the domain to the managed app, verify ownership using the displayed TXT record and configure the routing record to the instance. Check both domain verification and TLS status before directing visitors or webhooks to it. Use the application's intended public URL consistently when configuring integrations.

Supported managed apps offer plan upgrades and application-version upgrades from the console. Plan changes restart the instance; take a backup and schedule an interruption. Version upgrades have their own preparation and rollback process. Shrinking a plan is not supported when it would reduce persistent storage, so a smaller deployment requires a separate migration.

Storage Share is managed Nextcloud with a web interface, user accounts, file sharing and sync clients. An S3 bucket exposes an object API for applications and backup tools. Choose Storage Share for people collaborating on files; choose object storage when software needs S3-compatible access and bucket policies.

Yes. Connect Nextcloud desktop or mobile clients to the instance's HTTPS address, or use its WebDAV endpoint for compatible tools. The console provides mobile setup and connection information. Use the credentials for the Nextcloud user that should access the files, and check client sync status after the initial connection.

Storage Share supports custom domains and Nextcloud administration. Add the domain in the console and follow the displayed DNS steps; use the Nextcloud admin interface for apps and user management. Check compatibility, storage and connection needs before extending the instance with additional applications.

Storage Share plan changes are not available through the dashboard. Create a new instance on the desired plan and migrate data using Nextcloud tools or WebDAV, then verify files and user access before deleting the old instance. Keep an independent export: storage redundancy is not a replacement for a recoverable copy of files you delete or overwrite.

RabbitMQ is a message broker for applications that need to exchange work or events asynchronously. A producer publishes messages and consumers process them through the broker. Choose the protocol, queue behavior and application retry strategy for your workload, then use the connection details supplied for the managed queue instance.

Yes. Managed queues expose AMQP, MQTT and STOMP, with TLS variants for encrypted connections. When external access is enabled, each protocol uses the instance-specific port displayed under Connect to your queue. Do not use a standard RabbitMQ port copied from an example; the public ports are allocated for your instance.

Enable external DNS for the queue, then copy its hostname, protocol-specific TLS port and credentials from the console. External access opens that connection path; disabling it closes the path again. Anonymous access is disabled, so clients must authenticate. Use the encrypted protocol and check the configured virtual host when a client cannot connect.

Yes. Container Registry stores images under your project's registry namespace for use by CI pipelines and deployment targets. Tag and push images with the namespace shown in the console, and choose a plan that fits the repository and storage requirements. Registry storage is separate from the resources running a container.

Create a registry access key with push-and-pull or pull-only access. Use the token as Docker's password and an informational username such as your email address. The token is shown once; save it in your CI secret store and pass it without printing it. Registry keys are separate from DanubeData API tokens.

Yes. Select DanubeData Container Registry for your project's first-party images, or configure supported private-registry credentials for an external registry. Use the full image name and the intended tag. When an image cannot be pulled, check the namespace, tag and credential scope before changing application startup settings.

Registry plans limit storage and repository count. Check the exact quota error in the Docker output, then remove unneeded images or repositories, or choose a larger plan. Follow the registry guide for cleanup because deleting a local image does not remove the image stored remotely. Recheck usage before retrying a large push.

Install the published DanubeData CLI package and run danube auth for the browser authorization flow. You can also sign in with an API token. Run danube whoami to verify the account and projects you can access before making changes, and use the command help for the operation you need.

Yes. The CLI supports token-based, non-interactive workflows for supported commands. Store the token in the CI secret manager and provide it through the documented environment variable. Grant only the required project abilities and review the command's exit status and deployment result; submitting a deployment is not proof that the application became ready.

The Terraform provider covers supported compute, databases, caches, serverless services, static sites, object storage and access resources. Use the provider's current resource reference to check the exact schema and supported operations. Keep tokens in secret variables, review terraform plan and protect the state backend because state can contain sensitive resource values.

The Terraform guide documents import for supported resource types. Import associates a real resource with a state address; you still need matching configuration and a careful plan review afterward. Use separate state for separate environments and check which project the provider token targets before importing or applying changes.

Yes. The DanubeData Pulumi provider uses a Terraform bridge and offers TypeScript or JavaScript, Python, Go and C# SDKs. Check its own package schemas and resource catalog instead of assuming it exposes everything in Terraform or the API. Use secret configuration for the token and review the preview before applying.

The current Pulumi SDK does not expose the CPU platform field required for new VPS creation. Use the console or danube CLI for that operation while the limitation remains. The published Pulumi examples cover databases, caches and object storage; check the provider reference before designing an automated stack around another resource.

Yes. The MCP server exposes supported public API operations as tools authenticated with a DanubeData API token. Use the console's Connect an agent flow or the client examples in the guide, then select the toolsets and project permissions the agent needs. Resources an agent creates incur the same charges as resources you create yourself.

The guide provides configurations for Claude Code, Cursor, VS Code, Codex CLI and OpenCode. Other clients need Streamable HTTP and support for an Authorization header containing your API token. OAuth-only connectors cannot connect through that method yet. Check the guide for current client-specific settings instead of pasting a token into a public configuration file.

Yes. Give the agent a project-scoped token with only the read abilities it needs, and enable MCP read-only mode to exclude mutation tools. Read-only access can still expose sensitive values, including credentials when granted. Review the token's abilities and the data each tool returns before connecting an agent to a model provider.

Parameter groups are reusable collections of supported database or cache settings. Apply a group to multiple instances to keep their configuration consistent. Changes can affect every attached instance, so review the affected services and test the settings first. Some changes require a restart or engine-specific rollout.

Firewall rules control which network sources and ports can reach your resources. Allow only the IP addresses, networks or supported resource connections your application needs. Check both public access and private network paths when troubleshooting a connection, and keep SSH and database ports restricted wherever possible.

Use the console's resource metrics to track CPU, memory, disk and network usage, along with service-specific metrics where available. Metric alerts can notify you when thresholds are crossed, and uptime checks test a configured endpoint. Available metrics vary by service, so use the relevant product guide when planning your monitoring.

A snapshot captures a supported resource's data at a point in time. Create one manually or use the backup and scheduling options available for that service. Before restoring, check whether the operation replaces existing data or creates a new resource. Recovery options, retention and charges vary, so verify a successful backup and test the restore process.

Yes. The REST API provides token-authenticated access to supported resource operations. You can also use the CLI and supported infrastructure-as-code tools for repeatable workflows. Give each token the minimum abilities it needs, and use the API reference to check request fields, supported actions and rate limits.

A second copy in the platform backup store is separate from the source storage but remains in the same datacenter. It is not an offsite backup. Review the protection label on each recovery point, and keep an independent copy in another location if your recovery requirements include a datacenter-wide failure.

Supported resources let you set a backup policy with a time, timezone, schedule and retention period. Available choices vary by product and engine. Check the latest successful recovery point and protection status after enabling a policy. Turning scheduled backups off does not remove existing points immediately; their retention still applies.

Restore behavior depends on the product and action. Restore to a new resource leaves the source unchanged; Replace existing overwrites newer data and causes an interruption. Some actions are account-gated or unavailable for particular engines. Review the available action and data-loss cutoff in the restore wizard before confirming, and test recovery before an incident.

Yes. Uptime Checks test publicly reachable HTTP and HTTPS endpoints, including services hosted elsewhere. Configure the expected status code, a required response keyword or both. Private addresses and platform infrastructure are blocked. Checks originate from DanubeData infrastructure in Falkenstein, so they are not a measurement from every visitor's location.

An uptime check reports a failure after the configured number of consecutive unhealthy probes and sends a recovery notification when the endpoint returns to health. HTTPS checks also track certificate expiry. Review the expected response, failure threshold and notification preferences, and allow the monitoring requests through any firewall or bot protection on your endpoint.

Open Logs under Observability, select supported resources and filter by time, keyword, pattern or level. Drag across the volume chart to inspect a narrower period. Live tail follows one selected resource; a view with several resources refreshes periodically. Build output and one-off run output are separate from the runtime log archive.

No. Logs contain the output your application, build scripts and jobs produce; the platform does not automatically remove secrets or personal data from that text. Masked environment-variable fields in the console do not redact logs. Review logging at the source and avoid printing credentials, sensitive request data or full connection strings.

Yes. Metric alerts let you choose a supported resource metric, threshold, comparison and duration before notifying you. Requiring a condition to last for a period helps avoid alerts for brief spikes. Breach and recovery notifications appear through the documented channels; review notification preferences and test your monitoring setup.

DanubeData provides account protection through two-factor authentication and passkeys, project access controls, scoped API tokens, SSH keys and resource firewalls. The dashboard and API use HTTPS. Configure these controls for your project and secure your applications and VPS operating systems; the platform does not replace application-level security.

VPS disks, block volumes and storage behind managed databases, caches and queues are not encrypted at rest. Their volume snapshots are not encrypted at rest either, and backup copies are not guaranteed to be encrypted. Use application-level or guest-managed encryption if your workload requires it. Object Storage has separate server-side encryption settings.

Review the Data Processing Agreement, privacy policy and the selected service's data location before storing personal data. DanubeData hosts infrastructure in the EU, but your application still needs appropriate access controls, retention rules and a lawful basis for processing. Encryption and backup behavior differ by service, so include those in your assessment.

The service availability guide says DanubeData does not currently offer a contractual uptime-percentage SLA or service credits. Review the published availability guidance and contact support before onboarding if your workload needs contractual guarantees. Use the status page, monitoring and a tested recovery plan to assess and manage availability for your application.

Where available for your project and role, activity and audit views show recorded changes to resources and account settings. Use them to investigate who changed something and when. They are separate from application logs and service metrics; check the available event types and history before relying on them for a compliance requirement.

Open a support ticket while signed in to the console for help with your project, or email support@danubedata.ro if you cannot sign in. Requests outside the console need sender verification before we share account details or make changes. Include the affected service, what happened and when, but never send passwords or secret access keys.

Contact support through a signed-in console ticket or support@danubedata.ro. The service availability guide does not publish a guaranteed response-time schedule; discuss any contractual requirement before onboarding. For an urgent issue, include its impact, affected service, start time with timezone and the exact error, with secrets removed. Check the status page for an existing incident.

The documentation is available now at docs.danubedata.ro. It covers getting started, service configuration, billing, security and troubleshooting. Use the API reference for supported endpoints and request fields, or start with the product guide for the service you are deploying.

Visit status.danubedata.ro for published service status, incident updates and maintenance information. The status page covers platform services; use your resource metrics and uptime checks to investigate your own application. If your service has a problem that is not listed, open a support ticket with the impact and the time it began.

Send a suggestion through a console support ticket or the contact form. Explain the task you want to complete, what blocks you today and how often the problem occurs. Concrete examples help us assess a request; a suggestion does not create a delivery commitment or a promised release date.