HigherStack Architecture overview
The three parts that make up HigherStack Forms and how they fit together.
You don’t need to know how the plumbing works to use HigherStack Forms — but if you’re curious (or evaluating it for your stack), here’s the shape of it.
The three parts
| Part | What it is | Where it runs |
|---|---|---|
| Embed | The lightweight <higherstack-form> component that renders and submits a form. | On any web page |
| Functions (API + pages) | The backend: serves forms, accepts submissions, runs integrations, and renders the /f/… share pages. | Cloud Functions |
| Admin app | The builder and dashboard where you create forms and read results. | Your browser |
One definition, everywhere
A single form definition drives all three: the embed renders it, the server validates against it, and the builder edits it. That’s why a form behaves identically whether it’s embedded on your site, opened at its /f/… link, or previewed in the builder.
The key principle: clients never write the database directly. Every change — saving a form, submitting a response, inviting a member — goes through a server function that checks permissions first.
Still need help?
A dedicated support form is coming soon. In the meantime, jump back into the product or reach the team from the contact page.