A live form from a file you own.
Define your form in YAML and keep it in GitHub. Declarative Forms turns that definition into the working form — rendering questions, validating answers, and storing submissions.
Edit it yourself or with an AI agent. The source stays readable, versioned, and under your control.
# forms/beta-access.yamlversion: 1title: "Request beta access" sections: - id: application fields: - id: email type: email label: "Email address" validators: [required] - id: project type: long_text label: "What are you working on?" validators: [required] next: doneOne file. Three steps. A working form.
You define what the form should do. Declarative Forms supplies the runtime that makes it work.
Define the outcome. Let the questions adapt.
Adaptive sections use AI to refine questions around your objectives, reuse earlier answers, and produce validated, structured outputs. Completed outputs flow into the same submissions and connections as any other section.
Explore an adaptive form definition- 01
Describe the form
Start from an example, write the YAML yourself, or ask your coding agent to draft it against the published JSON Schema. Define the questions, validation, logic, and what should happen when the form is complete.
- 02
Push the definition
Commit the file to GitHub. Form changes become ordinary versioned changes you can inspect, review, compare, and revert alongside the work they support.
- 03
Open the form
Open the matching path on frms.dev and share it. Want to review a change first? Point the URL at another pushed branch and walk through the working form before you merge.
Keep the control. Skip building the form system.
Your definition can describe multi-step flows, conditional questions, validation, uploads, localized content, completion screens, and email or webhook connections.
Declarative Forms turns it into the experience respondents use, validates their answers, and stores submissions separately from your repository.
Use frms.dev when you want the hosted service. Self-host the open-source stack when control over the infrastructure matters.
Either way, the form remains an explicit artifact you can inspect, version, reuse, and automate.
This form is running on Declarative Forms.
The feature-request form beside this copy is not a mockup.
Its YAML definition lives in the public repository. Declarative Forms renders it here, stores its submissions, and a configured email connection sends requests to our inbox.
Open the form or inspect the definition that powers it.
Need something the product does not support yet?
Tell us what your workflow needs. If we accept the request, we’ll build it within 72 hours.
We’ll confirm acceptance and scope by email. The 72-hour window starts when we accept.
Your next form can start as a file.
Copy an example or ask your AI agent to draft the definition. Push it to GitHub, open the matching frms.dev URL, and you have a form you can continue to review, reuse, and automate.
No separate form-building workflow. No custom form application to maintain.
Create your first form