17 posts tagged with "eu"

Building a GraphQL API used to be a project. You stand up a server, wire it to a database, hand-write resolvers for every type, add a subscription transport, build an authorization layer, and keep all of it in sync with your schema as it changes. Weeks of plumbing before a single useful query runs.

The Launch a GraphQL API stack collapses that into one button. Pick it, accept the cost preview, and a few minutes later you have a production GraphQL API over your own PostgreSQL: queries, mutations, real-time subscriptions, and fine-grained permissions. No backend code. EU-resident from the first request.

Spreadsheets are how most teams actually model their work. A table of customers, a tracker of orders, a board of tasks. The tools that make this delightful, the Airtables of the world, give you a grid you can edit by hand and an API you did not have to write. What they do not give you is the database. Your data lives in someone else's product, in a shape you do not control, behind an export button.

Today you can have both. Launch a no-code database stands up NocoDB, the open-source Airtable alternative, wired to your own PostgreSQL. The editing experience is the spreadsheet you wanted. The thing underneath is a real SQL database, in your own account, resident in Europe, that you can query, scale, and back up like any other.

Retrieval-augmented chat is the demo everyone wants and almost nobody ships cleanly. The interface is easy. The plumbing is not. You need a vector store, somewhere to keep the documents, an inference endpoint that does not leak your data, and an app that knows how to reach all three. That is a database, a bucket, an API key, a handful of environment variables, and a firewall rule or two, all wired by hand before you see a single answer.

The rag-chatbot stack collapses that into one launch. Pick it, accept the cost preview, and a few minutes later you are chatting over your own data on infrastructure you own, resident in Europe.

Every platform you have ever shipped on hands you a bag of parts. A database here. A bucket there. An auth provider, a connection string, a set of S3 keys, a firewall rule, an environment variable to remember on Monday. Each part is real and each part works, but none of them know about each other. The wiring is the project. You spend the first afternoon copying credentials between dashboards before your app renders a single useful screen.

Today we ship the opposite of a bag of parts. create-foundry-app is live. One command scaffolds a Next.js app that already declares what it needs. One deploy provisions every one of those resources on FoundryDB, wires them together, and injects the credentials into the running app. No connection strings to copy. No firewall rules to open. No API keys to paste. You write the app and you ship the wired whole, resident in Europe, in one command and one deploy.

And because we know the first question every serious developer asks: it is open-source, it is MIT, and every primitive maps to an open standard, so the same app runs anywhere. You own the convenience, not a lock.

When an EU financial entity onboards a new cloud provider, the questionnaire arrives with a different vocabulary than the usual security review. It asks for your Register-of-Information entry. It asks for measured recovery times, not a promise that failover exists. It asks who the cloud sub-processor is, what region the data sits in, and how an incident would be recorded. The EU AI Act adds its own column: if you run AI infrastructure, where does the inference happen, what is logged, and what model inventory backs it.

Answering those questions used to mean a human assembling screenshots into a deck and hoping nobody changed a value between the screenshot and the audit. Today we are shipping the next phase of signed compliance evidence: per-organization, cryptographically signed evidence packets for DORA and the EU AI Act, alongside the SOC 2 and GDPR Article 30 ROPA packets we already produce. One API call returns the signed JSON and a clean PDF. Your auditor verifies it themselves against a key we publish.

Every managed platform you have ever used hands you a bag of parts. A database here. A bucket there. An API key, a network rule, a connection string, an environment variable. Each one is a primitive, and each one is yours to wire together. The pitch is "look how much you can build." The reality is an afternoon of plumbing before you see a single useful screen, and a config file that only you understand by Friday.

Today we flip that around. FoundryDB Stacks is live. A stack is the finished thing. One button stands up a complete, production-ready application, composed of those same primitives but already wired together, already metered, in minutes, and resident in Europe. You do not assemble the app. You launch it.

Every vendor security questionnaire asks the same questions. Where is the data stored? Is it encrypted at rest? Is it encrypted in transit? When was the last backup? How long do you keep audit logs? Answering them usually means a human logging into a console, taking screenshots, copying values into a spreadsheet, and hoping nobody changed anything between the screenshot and the audit.

The compliance report endpoint replaces that ritual with a single API call. It returns a JSON document describing your data posture across every service in your organization, and it attaches an HMAC-SHA256 signature over that document. An auditor can recompute the signature with a verification key and prove the report came from the platform and was not edited on the way to their desk.