Saltar al contenido

Recetas y apps

Integrations and connected accounts

Connect accounts at outside services so Setup can create what an app needs there, keep track of it and remove it with the app.

Aún sin traducir. Por ahora esta página solo está en inglés.

En esta página
  1. How Setup finds out what an app needs
  2. Connect an account
  3. Nothing is created before you confirm
  4. The resource ledger
  5. Removing resources
  6. Providers today
  7. What isn't done yet

Some apps need a service that doesn't run in Setup's sandbox: email sending through Resend, a database at Cloudflare or Neon, a backend at Convex. Setup doesn't rebuild those services. You connect your own account, and Setup creates a separate key, project or database there for each app.

Setup records everything it creates, shows it to you and removes it when you remove the app. Nothing is created until you have seen the plan and confirmed it.

How Setup finds out what an app needs

When Setup analyzes a project, it looks at dependencies, environment variable names and config files. If it spots an outside service, the recipe gets a requirement with a plain reason, for example that the app sends email.

When you start the app, the form shows an Outside services section with a choice for each requirement:

  • Create it for me. Setup creates what the app needs in your connected account and deletes it when you remove the app.
  • Use my own values. You enter keys you already have. Setup never deletes what you bring.
  • Set it up by hand. You follow the steps, then paste the values. When you remove the app, Setup reminds you to delete them.
  • Run without it. Only for optional services. The app starts without that feature.

If a self-hosted alternative exists, the section links to it, so you can keep everything in the sandbox.

Connect an account

Open Connections in the sidebar (/dashboard/connections, or /dashboard/<workspace>/connections for an organization) and choose Connect an account. Pick the service. The dialog lists the steps at the provider and, under "Grant only these permissions", the smallest set of rights Setup needs. Create the token there, paste it and confirm, for example with Connect Resend.

Setup checks the credentials with a read-only request where the provider offers one, then lists the account as Working. If a check fails, it shows Needs attention, and Check again repeats the check.

  • Only workspace admins can connect or disconnect accounts.
  • Credentials are stored encrypted, never shown again and never given to an app. The security model explains where they go.
  • Some services also offer sign-in with the provider instead of a token, but only when the operator of your Setup instance has registered an OAuth app for it. Otherwise you paste a token.

Nothing is created before you confirm

After you choose Create it for me and start the app, a runner plans the change with OpenTofu, and the app waits with "Waiting for your confirmation". The app page then shows Review what Setup will create: every resource in plain words, with a cost label (Free, Free tier or May cost money) and the provider's cost note.

Choose Create and start the app, or Remove this app instead. If the plan changed since you opened it, Setup says "The plan changed. Review it again." The runner only applies a plan that matches the one you confirmed, and while setting up it may only create, never change or delete.

If creating fails, Setup removes whatever it already created and says so. Try again plans once more.

The resource ledger

Every resource Setup creates becomes an entry in a ledger: the provider, the kind of resource, a plain name, its ID at the provider, a cost hint and the steps to remove it by hand. Setup names resources after the app and tags them where the provider supports tags, so they can be found again.

Each entry has an origin (Created by Setup, Set up by you or Found in your account) and a status such as Active, Removing or Leftover. The Outside services section on the app page lists an app's entries, and Connections shows how many each account holds.

Credentials for the account never reach the app. The app only gets the values of what Setup created for it, such as its own API key or database URL.

Removing resources

When you remove an app, Setup first removes the sandbox, then deletes the app's outside resources in reverse order and checks that nothing is left. The removal report says "Everything Setup created for this app was removed" or lists what still needs your attention, with steps. Things you set up by hand appear as a checklist. Failed removals are retried up to five times.

Note. Removing the app deletes databases and buckets Setup created, with everything in them. Save data you want to keep before you remove the app.

Leftovers are resources Setup created that belong to no app any more. Once a day, and whenever you choose Look for leftovers on an account, Setup lists what it named or tagged at that provider and matches it against the ledger. Not every provider lets Setup list its resources yet. Remove each leftover with Remove, or choose I deleted it if you removed it yourself.

Disconnecting an account with resources asks what to do: Remove them first deletes them (apps that use them stop working), Keep them and disconnect leaves them in your account and gives you removal steps when their app goes. Running apps keep their own keys either way.

Providers today

Setup knows 30 services. For each one it can detect the need, connect an account (with a check where the provider allows a read-only one) and guide you through setting it up by hand. For these, it can also create resources:

ServiceWhat Setup createsTested
ResendA sending-only API keyAgainst a fake of the provider's API
ConvexA project with a production deployment and deploy key (needs a paid Convex plan)Against a fake of the provider's API
CloudflareA D1 database or KV namespace with a token, or an R2 bucket with bucket-scoped keysWritten from documentation
Amazon Web ServicesAn IAM user with a key for SES sending, or a private S3 bucket with a key for itWritten from documentation
Google CloudAPI keys restricted to one API each, or a Gemini API keyWritten from documentation
SupabaseA project with database, auth, storage and APIWritten from documentation
NeonA project with its own Postgres database and loginWritten from documentation
DigitalOceanA private Spaces bucket with a key for itWritten from documentation
Setup demoA random password and a TLS key pair, no account neededCreated and removed for real

"Written from documentation" means the module passes OpenTofu's checks but hasn't run against a real account. The dashboard says so on each of them. Cloudflare can only scope D1 and KV tokens to the whole account.

Stripe, Vercel, OpenAI, Anthropic, OpenRouter, GitHub, Firebase, Clerk, Auth0, Sentry, PostHog, Microsoft Azure, SendGrid, Postmark, Mailgun, Twilio, Netlify, Fly.io, Hetzner Cloud, SMTP servers and S3-compatible storage support detection, connecting and guided setup, but Setup can't create resources there yet.

What isn't done yet

  • Only the demo module has created and removed resources for real. Resend and Convex were tested against fakes of their APIs; the rest are checked against documentation only.
  • Sign-in with a provider (OAuth) hasn't been tested with real providers, and no OAuth apps are registered by default.
  • The leftover search follows each provider's documented paging up to a limit. Paging was only exercised against the fakes.
  • If a runner dies while it creates resources, the record of what it created can be lost. Setup marks that setup as failed, and the daily leftover search finds what was created.
  • Modules come only from Setup's reviewed set, never from the analyzed project. Having the assistant write new modules from provider documentation is not built.

The assistant and MCP tools can explain requirements, list connections and resources and remove leftovers after you confirm. Connecting an account always happens on the Connections page, never in a chat.