A little over a year ago, in September 2025, DanubeData went live. I had built the infrastructure and dashboard around a simple goal: make it easier to deploy and manage the services an application needs.
The platform began with managed Redis. Virtual servers and managed databases followed. Since then, it has grown to include object storage, application hosting, deployment tools and several ways to automate the work. It is built in Romania, with the infrastructure running in Germany.
Our first anniversary passed in September. This retrospective includes the first few weeks of our second year, too. I wanted to take a moment to look at what we have built, acknowledge the parts we got wrong, and thank the people who have trusted DanubeData with their work.
The foundations for your application
Virtual machines gave the platform a place for workloads that need their own operating system. You can choose shared or dedicated vCPUs, configure a Linux server, and keep root access to run your own stack. Firewalls, private networking, SSH keys and cloud-init give you control over how it is set up and reached.
Alongside them, we added managed PostgreSQL, MySQL and MariaDB. Caching grew beyond Redis to include Valkey and Dragonfly.
These are familiar tools, and that is intentional. You can bring an application that already speaks PostgreSQL, Redis or AMQP and connect it to a managed service. The value of the platform is in the provisioning, visibility and maintenance around those tools, while you keep working with the software and protocols you know.
Tools for the work after deployment
Creating a database is one step. Understanding its data, preparing a change and investigating a problem are jobs you keep doing for as long as the application runs.
That is why we built SQL Studio for our CloudNativePG-managed PostgreSQL databases. It brings table browsing, SQL queries and schema exploration into the dashboard. Row edits stay pending until you review and commit them in a transaction, and the editor opens in read-only mode.
Snapshots and cloning added ways to prepare for changes and create separate environments from existing resources. PostgreSQL point-in-time recovery provides another recovery option for supported managed PostgreSQL instances. It is a PostgreSQL capability; recovery options differ across database engines.
The purpose of these additions is practical: spend less time moving credentials between tools, make changes deliberately, and have a recovery path to review before you need it.
Managed RabbitMQ for background work
We also added managed RabbitMQ for message queues. It gives applications a way to hand work to background workers and exchange messages between services, using familiar AMQP clients.
That brings another part of an application stack into the platform. Your web application can use a managed database for its records, a cache for frequently accessed data, and RabbitMQ to pass jobs to workers. You manage the application logic while DanubeData manages the broker infrastructure.
Storage for files and container images
With S3-compatible object storage, DanubeData gained a place for application uploads, media and backups. Existing S3 tools can connect to it, while the console provides a file browser for everyday work.
We added versioning, lifecycle rules, CORS settings and more control over access keys. Those controls let you decide how long objects stay, which application can reach a bucket, and what happens when a file is replaced. Versioning needs to be enabled on the bucket to retain previous versions.
The Container Registry completed another part of the deployment workflow: a private place to push Docker and OCI images, with scoped credentials for pushing and pulling. An application can now keep its files and its deployable images on DanubeData.
More ways to get an application online
Rapids brought serverless containers to the platform. You can deploy a container image, connect a Git repository or upload source code. Rapids handles the build where needed, HTTPS and traffic-based scaling, including scaling to zero when configured for it.
Static Sites added a simpler path for sites that produce HTML, CSS, JavaScript and assets. Publish from Git, the CLI or a ZIP upload, connect a domain, and use managed TLS. Deployment history lets you return to an earlier published version.
For people who want a particular application, we added managed WordPress, Ghost and n8n, with the application and its database provisioned together. Storage Share brought managed Nextcloud for file sharing and sync. The VPS Marketplace offers another route: install a prepared application on a server you administer yourself.
Each route serves a different need. A developer deploying an API, a business publishing a website and someone setting up a shared file workspace should each have a sensible place to start.
A faster and more stable platform
DanubeData is faster and more stable today than it was on day one. Improving the services already running here has been a continuing part of the work, alongside adding new ones.
That progress includes work on the infrastructure, more dependable deployment handling and a more responsive console. These improvements show up in everyday use: operating an existing service, moving through the dashboard and understanding what happened during a deployment. As the platform grows, continuing to improve its speed and stability matters just as much as expanding what it can do.
Seeing what is happening and what it costs
We added uptime checks for websites and APIs, metric alerts for resource usage, and a Log Explorer for investigating supported services. Together with resource graphs and deployment logs, these tools give you more context when something needs attention.
There has also been a steady stream of smaller console improvements: clearer connection details, searchable lists, shareable links and drawers that let you inspect an item without losing your place.
Billing received the same attention. Cost Insights and usage breakdowns help explain where spend comes from. Saved backup payment methods, card replacement and on-demand invoice payments make account administration easier. These changes matter when you are responsible for keeping an application running and need to understand both its status and its bill.
From the dashboard to your own workflow
The dashboard is one way to use DanubeData. The public API, danube CLI, Terraform provider and Pulumi provider give you other ways to manage supported resources from scripts, deployment pipelines and versioned infrastructure definitions.
This October, we added the DanubeData MCP server. Connect a compatible AI client with an API token and it can discover typed tools for nearly every operation in our public API. An agent can inspect resources, help investigate a failed deployment or create infrastructure within the permissions you grant it.
The permission boundary stays with the token. The MCP server adds no extra powers, and read-only access is available. That makes it possible to choose how much an agent can do, just as you would scope access for a script or a teammate.
A few milestones along the way
- September and October 2025: managed Redis, VPS instances and managed databases established the first services.
- December 2025: S3-compatible object storage joined the platform.
- Early 2026: the Terraform provider, serverless containers, Static Sites and recovery tools expanded what you could build and automate.
- May and June 2026: the Container Registry and SQL Studio connected more of the development workflow.
- Summer and autumn 2026: monitoring, service operations, console workflows and developer tooling continued to grow, followed by the MCP server in October.
The full changelog records the individual releases. Looking back at them together, the progress is in how many parts of running an application now fit into the same platform.
What running the platform taught us
This year also included outages and mistakes. They belong in this retrospective because customers experienced them alongside the new features.
In August, a storage server lost power. Object storage and the registry became unavailable, and new serverless and static-site deployments failed. Our monitoring detected the incident within minutes, but nobody was alerted effectively for hours. We published the full incident review and added voice-call paging, SMS and an external hardware watchdog.
That incident also exposed limits in how storage redundancy was arranged. Detecting a fault, reaching a person and surviving a machine failure are separate problems. Each needs its own design and verification.
A GitHub disruption exposed another dependency: repository-backed automation was part of our infrastructure control plane. We moved core repositories and build and deployment workflows to Forgejo, while retaining some external services. The lesson was to understand which customer operations depend on each service we use.
I want to keep publishing those explanations. When something fails, you deserve to know what happened, what it affected and what we changed. Useful infrastructure needs that ongoing care as much as it needs new capabilities.
Thank you for the first year
To everyone who has tried DanubeData, run a workload here, reported a problem or taken the time to ask a question: thank you. Choosing a small infrastructure provider means trusting the person behind it with something you care about. I take that seriously.
As we enter year two, the priorities are reliability, clearer everyday workflows and useful automation. There is more work to do in each of them. I want the platform to earn its place through how well it handles the services you already use, alongside the things we add.
If you have been away for a while, take another look at what is available. If you already use DanubeData, tell me what would make your work easier. That is a good place to start the next year.
Adrian Silaghi
Founder of DanubeData
