17 posts tagged with "eu"

Backups are the one copy of your data you hope you never need and cannot afford to get wrong. Until now, FoundryDB wrote them to storage we manage for you, which is the right default for most people. But if you have a data-residency requirement, an existing object-storage account you already audit, or a compliance rule that says backups live in a bucket you control, "the right default" is not enough. Now you can point a service's backups at your own S3-compatible bucket. We call it bring your own backup bucket, and it is live today.

Time-series data has a way of sneaking up on you. It starts as one metrics table, then it is device readings, then it is every event your product emits, and one morning that table is the biggest thing in your database and every dashboard query is slow. TimescaleDB is the classic answer inside PostgreSQL: turn the table into a hypertable, roll it up into continuous aggregates, and age it out with retention and compression. The catch is that all of that has always meant writing and babysitting the SQL yourself. Now it does not. Managed TimescaleDB is live on FoundryDB.

A cache is the easiest part of your stack to stand up and the hardest part to see into. Valkey starts in seconds, but the moment you want to know what is actually in it you reach for a client, open a TLS connection, and type commands by hand just to confirm a key exists. The fast, ephemeral store that should be the simplest thing you run turns into the one you have the least visibility into.

The Launch a cache with a console stack fixes that in one button. You get a managed Valkey cache with Redis Commander attached: an EU-resident in-memory store plus a browser console to browse keys, inspect values, and run commands, wired and metered, in minutes.

Spinning up a document database you can actually look at usually means two jobs. Provision MongoDB. Then, because the shell is not where you want to browse a collection at 2am, install a GUI, point it at the database, paste in a connection string, and remember to turn on TLS. The store you wanted was always one round of plumbing away from being usable.

The Launch a document store stack collapses that into one button. You get a managed MongoDB running on your own infrastructure, EU-resident, with a Mongo Express admin console wired on top, in minutes, with nothing to connect by hand.

Kafka is easy to write to and hard to see into. Standing up a broker is the start of the work, not the end: then you wire CLI tools and shell scripts together just to answer the basics. Which topics exist. How far behind is that consumer group. Is the broker even healthy. The event log you wanted was always one more afternoon of tooling away.

The Launch an event-streaming stack collapses that into one button. You get a managed Apache Kafka cluster with a browser console attached to it, EU-resident, in minutes, with nothing to wire by hand.

Building the backend for a new app is the same checklist every time. Provision a database. Put a GraphQL or REST layer in front of it. Stand up sign-in so users have accounts. Open a bucket for uploads. Then spend the rest of the day wiring those four pieces together with connection strings, access keys, and issuer URLs you paste between environment files. The product you actually wanted was always a day of plumbing away.

The Launch a realtime backend stack collapses that into one button. You get a complete backend on your own PostgreSQL: an instant real-time GraphQL API, end-user auth, and an object-storage bucket, wired together and EU-resident, in minutes, with no backend code to write.

Every product needs the same first afternoon of plumbing. Provision a database. Stand up an admin tool. Build sign-in and token issuance, or wire in a third party that holds your users hostage. Find somewhere to put uploads. Point a domain at it and get a certificate. None of it is the product you set out to build, and all of it has to exist before the product can.

The Launch a SaaS starter stack collapses that into one button. You get a SaaS backend in a box: your own PostgreSQL with a Directus studio over it, end-user auth, object storage, and a custom domain, wired together and EU-resident, in minutes.

Standing up a search stack usually starts the same way every time. Provision an OpenSearch cluster. Stand up Dashboards next to it. Wire Dashboards to the cluster with an endpoint and credentials you paste into a config file. Make sure the security plugin lets the two talk. Decide where Dashboards keeps its saved objects. Only then do you get to the part you actually wanted: indexing data and running a query.

The Launch a search workspace stack collapses that into one button. You get a managed OpenSearch cluster and a full OpenSearch Dashboards workspace, attached and EU-resident, in minutes, with nothing to wire by hand.

Getting to your first dashboard is rarely about the dashboard. It is about provisioning a database, standing up a BI tool, opening a port, copying a connection string, and praying the two halves agree on TLS. By the time anything renders, the afternoon is gone and the chart you actually wanted is still a row in a spreadsheet.

The Launch a BI workspace stack collapses all of that into one launch. You get a complete Metabase workspace wired to your own PostgreSQL, EU-resident, with dashboards in minutes. You do not assemble it. You launch it.

Standing up a headless CMS usually means a weekend. Provision a database. Pick a CMS. Wire it to the database with a connection string you paste into an environment file. Open a firewall rule. Mint an API token. Then, finally, model your first collection. The content platform you actually wanted was always one good afternoon of plumbing away.

The Launch a CMS stack collapses that into one button. You get a production headless CMS running on your own PostgreSQL, EU-resident, in minutes, with nothing to wire by hand.