DEV Community: Pawan Bisht

Your Database Backup Exists. But Can You Actually Restore It?

Pawan Bisht — Mon, 14 Sep 2026 06:55:53 +0000

Your Database Backup Exists. But Can You Actually Restore It?

Most teams have database backups.

They run on a schedule. They complete successfully. They are stored in S3, RDS, or another backup system. Monitoring tells you that the backup job is green.

Then one day, something goes wrong.

A database is corrupted.
A production deployment deletes important data.
An infrastructure failure takes down the database.
Someone needs to recover yesterday's state.

And suddenly, the important question isn't:

"Did the backup complete?"

It's:

"Can we actually restore it?"

That distinction is easy to overlook.

A successful backup job proves that data was copied somewhere. It does not necessarily prove that the backup is usable.

The backup paradox

Imagine a team with this setup:

PostgreSQL runs in production.
Automated backups run every night.
AWS RDS manages the snapshots.
The team receives an alert if a backup fails.
Everything has been green for the last six months.

From an operational dashboard, things look great.

But what happens if the team discovers that:

a required table wasn't included,
permissions are incorrect after restoration,
an application expects an index that isn't present,
foreign-key relationships are broken,
critical data is missing,
or restoring the snapshot takes significantly longer than the team's RTO?

The backup technically exists.

But the recovery process is broken.

This is why backup testing and restore testing are two different things.

A backup is not a recovery plan

A useful mental model is:

Backup

"We have a copy of the data."

Restore

"We can turn that copy back into a working database."

Recovery validation

"The restored database contains the data and structure our application actually needs."

That third step is where many systems stop short.

You don't necessarily need to run the entire application to validate a database restore.

You can test the database itself.

For example:

checks:
  - type: connect

  - type: schema
    expect_tables: [customers, orders]

  - type: row_count
    table: orders
    min: 1

  - type: foreign_key
    table: orders
    references: customers

  - type: golden_query
    query: "SELECT count(*) FROM orders"
    expect_min: 1

These checks answer practical questions:

Can we connect?
Are the important tables there?
Is the expected data present?
Are relationships intact?
Does a critical query still work?

The exact checks will depend on the application, but the principle is the same:

Don't just verify that a backup exists. Verify that the restored state satisfies known invariants.

Why manual restore testing doesn't happen often

At this point, someone usually says:

"We already know we should test restores."

True.

The problem is that actually doing it manually is inconvenient.

A realistic restore test might require someone to:

Find the correct snapshot.
Restore it into a temporary database.
Wait for the database to become available.
Configure credentials.
Connect to it.
Run validation queries.
Check the results.
Record how long recovery took.
Delete the temporary database.
Repeat the process periodically.

Nobody wants to spend their Friday afternoon doing this.

So the restore test gets postponed.

Then postponed again.

Eventually the team has a backup strategy that has never been seriously exercised.

Recovery time is part of the test

There is another problem with only checking whether a restore succeeds.

How long did it take?

Suppose your recovery objective is one hour.

Your backup restores successfully, but it takes three hours.

Technically, the backup works.

Operationally, it fails your recovery requirement.

That's why restore validation should measure recovery time as well.

A useful report might look conceptually like this:

Restore Validation: PASS

Snapshot: latest
Restore time: 18m 42s

Checks:
✓ customers table exists
✓ orders table exists
✓ orders row count >= 1
✓ foreign key orders -> customers intact
✓ golden query passed

Recovery objective: 60m
Result: PASS

Now you have evidence rather than an assumption.

What should you test?

You don't need to test every possible database property.

Start with the things that matter to your application.

1. Connectivity

Can you connect to the restored database?

This sounds obvious, but it establishes the basic recovery path.

2. Schema

Are critical tables present?

For example:

users
orders
payments
subscriptions

A restore that is missing an important table shouldn't be considered healthy.

3. Data volume

Row counts can provide a simple sanity check.

For example:

- type: row_count
  table: orders
  min: 100

This isn't a replacement for deep data validation, but it can detect obvious failures.

4. Relationships

Database relationships are important.

If orders.customer_id references customers.id, you want to know that the restored data doesn't contain orphaned records.

5. Critical queries

Every application has queries that represent important business functionality.

For example:

SELECT count(*) FROM orders;

Or something more meaningful:

SELECT count(*)
FROM payments
WHERE status = 'completed';

These can become "golden queries" that must continue to work after recovery.

6. Data freshness

For systems that depend on continuously updated data, freshness can matter as much as row count.

For example:

- type: freshness
  table: orders
  column: created_at
  max_age: 24h

A database containing millions of rows isn't necessarily healthy if the newest data is several days old.

7. Indexes and other structural requirements

Sometimes the data is present but the database isn't operationally equivalent to what the application expects.

Critical indexes can also be validated as part of recovery testing.

The important part: automate the boring work

This is the idea behind Revenant.

Revenant is a small CLI designed around one question:

Can this database backup actually be restored and validated?

It connects to PostgreSQL and runs checks defined in a revenant.yaml file.

For a local database, the workflow can be as simple as:

export DATABASE_URL='postgres://user:pass@localhost:5432/mydb?sslmode=disable'

revenant init --plan my-app --force
revenant verify

init can inspect an existing PostgreSQL database and generate a starting configuration.

verify then runs the defined validation checks.

For AWS RDS, the workflow can go further.

Revenant can:

Find the latest RDS snapshot.
Restore it into a temporary sandbox.
Run the configured checks.
Measure recovery time.
Generate a report.
Delete the sandbox.

The goal isn't to replace your backup system.

AWS RDS, PostgreSQL, cloud providers, and backup tools already do the actual backup work.

The missing layer is often proof that recovery works.

Treat recovery testing like CI

One of the most useful ways to think about restore testing is to treat it like a test suite.

You already test application code.

You might run:

go test ./...

before merging code.

You probably test deployments.

You may run infrastructure checks.

But your backup system can also have tests:

Backup
   ↓
Restore
   ↓
Connect
   ↓
Validate schema
   ↓
Validate data
   ↓
Validate relationships
   ↓
Measure recovery time
   ↓
Generate evidence

And this process can run periodically in CI.

For example, a weekly GitHub Actions workflow can restore a recent snapshot, execute the validation suite, and upload the resulting report.

Now recovery isn't something you hope works during an incident.

It's something you've exercised recently.

Keep the application out of the restore test

One design choice is particularly useful here.

Database recovery validation doesn't necessarily need to understand your application code.

Your application could be written in:

Node.js
Python
Go
Ruby
Java
Rails
Django
or something else.

The database doesn't care.

A database-focused recovery tool can validate the database directly through PostgreSQL.

This makes the approach language-agnostic.

You define what matters in configuration:

checks:
  - type: connect

  - type: schema
    expect_tables: [customers, orders]

  - type: row_count
    table: orders
    min: 1

  - type: foreign_key
    table: orders
    references: customers

The tool doesn't need to inspect your models or application source code.

That separation makes the recovery test easier to run independently from the application.

Don't forget cleanup

Automated restore testing introduces another problem: temporary infrastructure.

If every restore creates an RDS instance and something goes wrong before cleanup, you can end up with abandoned resources.

That's particularly painful with cloud infrastructure because forgotten resources can become forgotten bills.

A recovery-testing system therefore needs cleanup as part of the workflow, not as an afterthought.

For example, a safety-net command can look for Revenant-managed sandbox instances older than a configured age and remove them:

revenant reap --max-age 4h --region us-east-1

And CI workflows can run cleanup even when the validation job fails.

The rule should be simple:

If the restore test creates infrastructure, the restore test owns the cleanup.

Evidence matters

Another advantage of automated restore testing is that every run can produce evidence.

For example:

report.json
report.md

The JSON report can be consumed by automation.

The Markdown report can be attached to a CI run, reviewed by engineers, or retained as operational evidence.

Instead of saying:

"We think our backups work."

You can say:

"The latest snapshot was restored on September 14. Recovery took 19 minutes, all six validation checks passed, and the sandbox was successfully destroyed."

That's a much stronger statement.

Start small

You don't need a huge disaster-recovery testing platform on day one.

Start with three questions:

Can I connect?

If not, recovery has already failed.

Is the important data there?

Check critical tables, approximate row counts, and a few important queries.

Can I recover within my target?

Measure the actual restore time.

Then expand the test suite as you discover more failure modes.

The goal isn't to create a perfect replica of production.

The goal is to eliminate dangerous assumptions.

The uncomfortable question

Every engineering team should eventually be able to answer this:

If our production database disappeared right now, when was the last time we proved that our backup could become a working database?

If the answer is "we've never tested it," your backup system isn't necessarily broken.

But your confidence in it is an assumption.

And assumptions are exactly what disaster recovery is supposed to eliminate.

Backups are important.

Restores are the proof.

About Revenant

Revenant is an open-source CLI for PostgreSQL backup recovery validation. It supports local PostgreSQL databases and AWS RDS restore workflows, with YAML-based validation checks and JSON/Markdown reports.

The project is available on GitHub:

Revenant CLI on GitHub

For teams using GitHub Actions, there is also a dedicated action:

Revenant GitHub Action

PostgreSQL Backup Isn’t Enough: How We Automated Restore Testing

Pawan Bisht — Mon, 07 Sep 2026 06:31:53 +0000

I Automated the Database Restore Drill Nobody Runs Until 3 AM

There’s a ritual almost every Postgres team knows.

Backups are configured.

Alerts are in place.

Someone has probably written a disaster recovery document.

And somewhere in that document is a sentence that says:

“We test restores regularly.”

Except “regularly” usually means “when we get around to it.”

That’s the problem we wanted to solve with Revenant.

Instead of asking someone to remember to run a restore drill every quarter, we wanted the infrastructure to ask the question itself:

Can this database actually be recovered?

So we built a way to run that check every week, directly from CI.

No Go installation.

No application code.

No ORM integration.

No special framework plugin.

Just PostgreSQL, a small YAML file, and a GitHub Action.

Here’s what the setup looks like.

First, define what a healthy restored database means for your application.

Create a revenant.yaml:

plan: production-sanity

database:
  engine: postgres
  connection: ${DATABASE_URL}

checks:
  - type: connect

  - type: schema
    expect_tables:
      - users
      - orders

  - type: row_count
    table: orders
    min: 1

  - type: foreign_key
    table: orders
    references: users

  - type: golden_query
    query: "SELECT count(*) FROM orders WHERE created_at > now() - interval '7 days'"
    expect_min: 0

  - type: freshness
    table: orders
    column: created_at
    max_age: 48h

You can write the checks yourself, or start from an existing database:

export DATABASE_URL='postgres://...'

revenant init --plan production-sanity --force

Revenant looks at the live schema and generates a starting configuration.

You review it.

You change the checks that matter to your application.

Then commit it to the repository.

The important part is that Revenant doesn't need to understand your application.

It doesn't care whether you're running Next.js, Django, Rails, or a ten-year-old monolith.

It only needs to know what a healthy PostgreSQL database looks like.

Then comes the part that makes this useful.

Put the validation into GitHub Actions.

name: Weekly restore validation

on:
  schedule:
    - cron: '0 4 * * 1'

  workflow_dispatch:

jobs:
  validate:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: 277pawan/revenant-action@v1.0.3
        with:
          version: v0.1.1
          config: revenant.yaml
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}

      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: restore-validation-report
          path: |
            report.json
            report.md
          if-no-files-found: ignore

Add DATABASE_URL as a GitHub secret.

Run it once manually.

After that, your repository has a weekly restore validation running automatically.

The output is deliberately boring.

And that's a good thing.

Restore Validation: PASS

Wrote report.json
Wrote report.md

If something is wrong, you don't just get “backup failed.”

You get the reason.

A table is missing.

A critical table is empty.

A foreign key is broken.

A business query returns unexpected results.

The restored data is stale.

That's much more useful than discovering the problem at 3 AM.

And there's another level.

If you're using AWS RDS, you can validate an actual snapshot rather than simply validating the live database.

Revenant can restore the latest snapshot into a temporary sandbox, run the same validation checks against it, record the recovery time, and then tear the sandbox down.

The workflow is essentially:

Restore.

Validate.

Measure.

Delete.

If something goes wrong halfway through, revenant reap acts as the safety net and cleans up orphaned sandboxes.

You're not maintaining a second production database.

You're renting proof for a short period and then deleting it.

That distinction matters.

Because disaster recovery isn't really about having a backup.

It's about knowing what happens after you click:

Restore.

We also wanted the tool to be easy to debug before throwing it into CI.

So there's a doctor command:

revenant doctor

It checks configuration, environment variables, and connectivity before you start wondering why your GitHub Action isn't working.

And the GitHub Action itself is intentionally simple.

It downloads a pre-built Revenant binary from GitHub Releases and runs it.

Your CI environment doesn't need Go.

Your application doesn't need to change.

It's just another CLI running as part of your workflow.

Where we are today

Revenant is open source and Apache-2.0 licensed.

The current releases include:

CLI v0.1.1

GitHub Action v1.0.3

PostgreSQL validation checks

JSON and Markdown reports

AWS RDS snapshot restore validation

Commands for doctor, init, verify, snapshot, and reap

CLI:
https://github.com/277pawan/revenant-cli

GitHub Action:
https://github.com/277pawan/revenant-action

Example workflows:
https://github.com/277pawan/revenant-cli/tree/main/examples/workflows

But honestly, this is still early.

There is a lot more we want Revenant to become.

We're thinking about fleet-wide restore drills, scheduled recovery testing across many databases, centralized evidence, signed reports, audit workflows, recovery-time tracking, and eventually a hosted control plane for teams that have outgrown a single YAML file.

We don't want to build all of that in isolation.

That's where I'm asking for your help.

Revenant is open source, and we're actively looking for people who want to contribute.

You don't have to build a huge feature.

Try it against your own PostgreSQL database.

Tell us where the workflow doesn't make sense.

Open an issue.

Suggest a check you think is missing.

Improve the documentation.

Add an example.

Test it against a setup we haven't thought about.

Or, if you're interested in the bigger vision, contribute code and help us shape what this becomes.

The roadmap is intentionally bigger than what's shipping today.

The more real-world feedback and contributions we get now, the more useful we can make the tool for everyone.

Because I don't think “we have backups” should be the end of the conversation.

It should be the beginning.

**Backups prove you copied the data.

Revenant proves you can recover it.**

If that's a problem your team has been putting off, try it this week.

And if you have an idea for what Revenant should become, I'd genuinely like to hear it.

The project is open source.

Come build it with us.

PostgreSQL #OpenSource #DevOps #SRE #DisasterRecovery #GitHubActions #AWS #RDS #Database #CI #Infrastructure #Backup

I built Revenant to prove PostgreSQL backups actually restore — in CI, on AWS, without touching your app code.

Pawan Bisht — Mon, 07 Sep 2026 06:27:47 +0000

A team I know had green backup alerts for six months straight.

Every day, the backups completed.

Snapshots were being created on schedule. Retention was configured. Monitoring was quiet.

As far as everyone could tell, the database was protected.

Then one day, they needed to restore it.

The snapshot restored successfully.

The database started.

And then the application broke.

A migration that should have been there had never been applied to the restored instance. A critical table was empty. The first real query hit a foreign key constraint and failed.

Nothing was wrong with the backup.

The problem was that nobody had ever proved the restore actually worked.

That distinction sounds obvious, but it's surprisingly easy to miss.

Most teams have automated checks around whether a backup job completed. They know a snapshot exists. They know how long it's retained. They know the storage is healthy.

But a successful backup only tells you that you copied some bits somewhere.

It doesn't tell you whether those bits can become a working database again.

And that's the gap I wanted to solve.

So I built Revenant.

Revenant is an open-source CLI that validates PostgreSQL restores.

The idea is deliberately simple.

You tell Revenant what a healthy database looks like in a revenant.yaml file.

Maybe your customers and orders tables need to exist.

Maybe orders should never be empty.

Maybe the foreign key between orders and customers must remain intact.

Maybe there is a query that should always return data.

Maybe the newest order shouldn't be more than 24 hours old.

Those rules are specific to your business, so Revenant doesn't try to guess them.

You define them once.

Then Revenant runs them every time you validate a database.

For example:

plan: my-app-validation

database:
  engine: postgres
  connection: ${DATABASE_URL}

checks:
  - type: connect

  - type: schema
    expect_tables:
      - customers
      - orders

  - type: row_count
    table: orders
    min: 1

  - type: foreign_key
    table: orders
    references: customers

  - type: golden_query
    query: "SELECT count(*) FROM orders WHERE status = 'paid'"
    expect_min: 1

  - type: freshness
    table: orders
    column: created_at
    max_age: 24h

Then:

revenant verify

The result isn't just "command succeeded."

You get evidence:

✓ customers table exists
✓ orders row count 42 >= 1
✓ foreign key orders -> customers intact

Restore Validation: PASS

Wrote report.json
Wrote report.md

That report is useful because it answers a much more important question than "did the backup job run?"

It answers:

Can we actually use this database?

And because Revenant only talks to PostgreSQL, it doesn't care what your application is written in.

Node. Python. Go. Rails. Java.

It doesn't need to read your source code or understand your application architecture.

You can run it locally, in CI, or on a schedule.

We also built a GitHub Action so teams don't need to install Go or manage another runtime just to run the checks.

Set your DATABASE_URL, add the workflow, and let the pipeline periodically prove that your database still passes its restore validation rules.

The more interesting part is what happens with AWS RDS.

For RDS, you can take the validation one step further.

Revenant can find an RDS snapshot, restore it into a temporary sandbox, run your validation plan against the restored database, collect the results, and tear the sandbox down.

In other words, you're not just checking whether a database looks healthy today.

You're testing the thing you actually care about:

Can we recover from the backup we would use during an incident?

The current release includes the CLI, GitHub Action, PostgreSQL validation checks, JSON and Markdown reports, and the AWS RDS restore workflow.

It's free, open source, and Apache-2.0 licensed.

We've also started thinking about what comes next.

A single revenant.yaml works well when you're validating one application.

But organizations eventually have dozens or hundreds of databases.

That's where we're heading with the hosted layer: fleet-wide restore drills, scheduling, signed evidence, and a central place to see whether your databases can actually be recovered.

But the core idea won't change.

I've seen too many disaster recovery plans boil down to:

"We have backups."

I think the better statement is:

"We have backups, and we prove that they restore."

Because the worst time to discover that your backup doesn't actually recover your business is when you're already in the middle of an incident.

That's why I built Revenant.

If this problem sounds familiar, give it a try.

CLI: https://github.com/277pawan/revenant-cli

GitHub Action: https://github.com/277pawan/revenant-action

And if you find something that breaks, open an issue.

We're building this with early users, and those real-world restore failures are exactly what we want to learn from.

**Don't just back up your database.

Prove you can recover it.**

React Hook Form vs Formik vs Schema-Driven Forms: Which Approach Should You Use?

Pawan Bisht — Tue, 01 Sep 2026 06:44:50 +0000

For Better Clarity Please visit rest you can continue with this article :- React-Form-Toaster (Official Doc) Building a form in React is easy when the fields are fixed.

Choosing a React form solution can be surprisingly difficult.

There are popular libraries.

There are different validation strategies.

And then there is the question of whether you even need a traditional form library.

Three approaches you'll frequently encounter are:

React Hook Form
Formik
Schema-driven forms

They solve overlapping problems, but their design philosophies are different.

Let's look at how they compare.

React Hook Form

React Hook Form focuses on performant and flexible form handling.

A simple example looks like:

const {
  register,
  handleSubmit,
  formState: { errors },
} = useForm();

return (
  <form onSubmit={handleSubmit(onSubmit)}>
    <input {...register("email", { required: true })} />

    {errors.email && <p>Email is required</p>}

    <button type="submit">
      Submit
    </button>
  </form>
);

The developer still explicitly creates the form UI.

The library helps manage:

registration
form state
validation
errors
submission

This is a great model when you want detailed control over your components.

Formik

Formik takes another approach to form state and validation.

A simplified example:

<Formik
  initialValues={{
    email: "",
  }}
  onSubmit={handleSubmit}
>
  <Form>
    <Field name="email" type="email" />
    <button type="submit">
      Submit
    </button>
  </Form>
</Formik>

Formik provides abstractions for managing form state, fields, validation, and submission.

Again, though, your React component generally defines the UI.

Schema-driven forms

Schema-driven forms move the abstraction one step further.

Instead of primarily describing how the form should be rendered in JSX, you describe the form as data.

For example:

const schema = [
  {
    name: "email",
    type: "email",
    label: "Email",
    required: true,
  },
  {
    name: "country",
    type: "select",
    label: "Country",
    options: [
      {
        label: "India",
        value: "IN",
      },
      {
        label: "United States",
        value: "US",
      },
    ],
  },
];

The rendering system interprets that configuration.

Conceptually:

Schema
  ↓
Renderer
  ↓
Form UI

This is particularly useful when forms are dynamic.

So what's the difference?

A simplified way to think about the approaches is:

Approach	Main abstraction
React Hook Form	Form state and field registration
Formik	Form state and form lifecycle
Schema-driven	Form definition and rendering

This doesn't mean React Hook Form or Formik can't work with schemas.

They absolutely can.

The distinction is mainly about where your application puts the form definition.

When React Hook Form is a great choice

Choose React Hook Form when:

you want direct control over JSX
you have custom UI components
you need fine-grained form state management
your forms are mostly developer-defined
you want a mature ecosystem

For many applications, this is an excellent default.

When Formik makes sense

Formik can be useful when:

your team is already familiar with it
you prefer its form-state model
your existing application already uses Formik
you have established Formik components and patterns

The best library is often the one your team already knows and maintains effectively.

When schema-driven forms make sense

Schema-driven forms become particularly interesting when:

forms are generated dynamically
you have many similar forms
fields come from configuration
form definitions come from an API
you need reusable form structures
you want to separate form configuration from UI rendering

For example, imagine an admin system with 100 different forms.

Writing and maintaining 100 large JSX components can become repetitive.

A schema-driven renderer can allow those forms to share the same rendering infrastructure.

React-Form-Toaster

This is the problem space that react-form-toaster focuses on.

Instead of replacing every possible form library, it provides a schema-driven approach for building dynamic React forms.

It can be useful when you want features such as:

dynamic fields
conditional fields
arrays
nested structures
TypeScript
Zod validation
file uploads
modal forms
inline forms
toast feedback

The important point is that this is not necessarily an "either/or" decision.

Different projects can benefit from different abstractions.

Don't choose based only on popularity

A common mistake is asking:

"Which React form library is the most popular?"

A better question is:

"What problem does my application actually have?"

If you have a highly custom form with unique UI requirements, a traditional form-state library may be ideal.

If you have dozens of forms that follow predictable patterns, schema-driven forms may save significant development time.

A practical decision guide

Choose React Hook Form if:

You want control over the UI and need powerful form-state management.

Choose Formik if:

Your team prefers its architecture or you're maintaining an existing Formik codebase.

Choose schema-driven forms if:

Your forms themselves need to be configurable and dynamically generated.

Consider combining approaches if:

You need schema-based definitions but also want a mature form-state or validation engine underneath.

These approaches aren't mutually exclusive.

Final thoughts

There isn't a universal winner.

React Hook Form, Formik, and schema-driven approaches solve different layers of the form problem.

The most important question is whether your application's complexity is primarily coming from:

form state

form structure.

If the problem is mostly form state, a library such as React Hook Form can be an excellent choice.

If the problem is that you have many dynamic form structures, schema-driven forms become much more compelling.

That's exactly where tools like react-form-toaster can fit into a React application's architecture.

The goal isn't to use the most popular form library.

The goal is to choose the abstraction that makes your particular forms easier to build and maintain.

React Form Toaster 2.0.9: What Changed and Why You Might Want to Try It

Pawan Bisht — Mon, 24 Aug 2026 10:48:15 +0000

If you've built a moderately complex form in React, you probably know how quickly the code grows.

Validation.
Conditional inputs.
Loading states.
Error messages.
Password toggles.
File inputs.
Repeatable fields.
Notifications.
Styling.

And eventually, the form component becomes much larger than the feature itself.

That's the problem React Form Toaster is designed to reduce.

With version 2.0.9, I've added and improved several capabilities that make schema-driven forms more practical for real applications.

🚀 Install React Form Toaster

You can get React Form Toaster from npm:

React Form Toaster on npm

npm install react-form-toaster

Then import it into your application:

import Formbox from "react-form-toaster";
import "react-form-toaster/dist/index.css";

What makes it different?

Instead of manually creating every field, you describe your form:

fields={[
  {
    name: "email",
    type: "email",
    label: "Email",
    placeholder: "Enter your email",
    required: true,
  },
]}

Validation can be handled through Zod:

const schema = z.object({
  email: z.string().email("Enter a valid email"),
});

And submission stays simple:

<Formbox
  schema={schema}
  fields={fields}
  onSubmit={async (data) => {
  console.log(data);
  }}
/>

For toast experiment you can try this!!

<Formbox
  schema={schema}
  fields={fields}
  toast = {{
    loading:"Processing data...",
    success:"Congratulation data saved🥂",
    error:"Found Some error!!",
    position:"bottom",
  }}
  onSubmit={async (data) => {
     await new Promise((resolve)=>{
     setTimeout(()=>console.log(data);resolve(),1500)
    })
  }}
/>

The interesting part of 2.0.9 is how much more control you have around that basic idea.

🎨 Styling: Tailwind + Inline CSS

You can now approach styling based on what you actually need.

For utility classes:

className="rounded-xl px-4 py-3 font-semibold"

For exact custom values:

style={{
  backgroundColor: "#12141c",
  border: "1px solid #252836",
  color: "#ffffff",
}}

You can also customize things such as:

labels
validation errors
buttons
inputs
focus states
password toggles
dropdowns
containers
required indicators

This gives you more control without having to fight the library when building a custom UI.

🔀 Conditional Fields

Dynamic forms are another important part of 2.0.9.

A field can depend on another field:

{
  name: "companyName",
  type: "text",
  label: "Company Name",
  showWhen: {
    field: "accountType",
    equals: "business",
  },
}

This lets you build forms where the UI changes according to the user's choices without manually maintaining a separate visibility state for every conditional input.

🔁 Repeatable Fields

Array fields are supported for scenarios where users need to add multiple values or groups of inputs.

This is useful for things like:

multiple addresses
team members
products
contact information
dynamic configuration

The goal is to keep these structures inside the schema instead of turning your component into a collection of state-management code.

🔔 Bring Your Own Toast Library

You don't have to use the built-in toast system.

Disable it:

<Formbox toast={false} />

Then use whatever notification solution your application already uses.

This keeps React Form Toaster focused on forms instead of forcing your entire application's notification architecture.

🌓 Inline or Modal

Need a form inside a page?

<Formbox mode="inline" />

Need a popup?

<Formbox mode="modal" />

Same library, different presentation.

🧠 Why I'm Building This

The idea behind React Form Toaster isn't to create another form library with hundreds of abstractions.

I'm trying to make a common workflow simpler:

Define → Validate → Render → Submit → Notify

without repeatedly rebuilding the same infrastructure.

There is still a lot I want to improve, and that's where community feedback becomes important.

📚 Documentation + Interactive Playground Coming Soon

One of the next major things I'm working on is a dedicated documentation website for React Form Toaster.

The README contains a lot of information, but I don't want developers to have to dig through a giant README to understand the library.

The new documentation site will make it easier to find:

installation
field types
validation examples
styling options
conditional fields
array fields
toast configuration
complete examples
API references

But there's something else I'm especially excited about:

🧪 An Interactive Playground

The documentation will include a playground where you can actually experiment with React Form Toaster.

Instead of only reading about the API, you'll be able to play with the form configuration, try different fields and options, see how the form behaves, and learn by experimenting.

I think this will make getting started with the library much easier.

Read → Try → Change → Learn.

The documentation website and playground are planned to be released in the next few days. 🚀

🤝 Contribute to React Form Toaster

React Form Toaster is an open-source project, and contributions are always welcome.

If you find a bug, have an idea, or want to improve the library, I'd genuinely love to hear from you.

You can contribute by:

🐛 Reporting bugs
💡 Suggesting features
🔧 Opening pull requests
📖 Improving documentation
🧪 Testing new features
⭐ Sharing the project with other React developers

You can find the project and contribute on GitHub:

React Form Toaster on GitHub

You can also find me on GitHub:

277pawan

If you have an idea for improving the library, don't hesitate to open an issue or start a discussion.

❤️ Back the Project

Open-source software takes time to build, maintain, document, and improve.

If React Form Toaster has saved you development time or helped you build something, you can support the project by backing my work.

Your support helps me spend more time on:

🚀 New features
🐛 Bug fixes
📚 Better documentation
🧪 Testing and improvements
🧪 Improving the interactive playground
🌐 The upcoming documentation website
🔮 Future versions of React Form Toaster

If you'd like to support the project financially, you can use the GitHub Sponsors option on my profile.

Every contribution — whether it's a sponsorship, a ⭐ star, a bug report, a pull request, or simply sharing the project — means a lot.

Final Thoughts

React Form Toaster 2.0.9 is another step toward making complex React forms easier to build without sacrificing customization.

If you're working on a React project with dynamic forms, give it a try.

📦 Get React Form Toaster on npm

💻 Explore the source code on GitHub

👤 Follow me on GitHub

If something doesn't work the way you'd expect, let me know. Open an issue, suggest an improvement, or contribute a fix.

And if you like the idea behind the project, give the repository a ⭐ — it genuinely helps the project.

2.0.9 is out. Documentation + Playground are coming next. 🚀

Thanks for checking out React Form Toaster and supporting open source. ❤️

🚀 React-Form-Toaster 1.1.3 is here. Build powerful forms in React/Next.js with ease, flexibility, and clean UX baked right in.

Pawan Bisht — Thu, 23 Apr 2026 05:12:54 +0000

🚀 React-Form-Toaster 1.1.3

Now faster, smarter, and more customizable than ever. Build powerful forms in React/Next.js with ease, flexibility, and clean UX baked right in.

Say hello to the latest version of React-Form-Toaster (1.1.3)! 🎉

We've made it even easier, faster, and more powerful with much stability to create dynamic forms in React — without writing repetitive code. Whether you're building a signup form, feedback tool, or a confirmation popup, this library has you covered.

🔥 What's New in 1.1.3?

File Upload — More keys for better file upload with new validation!
Password Toggle — Beautiful default UI with full customization; use any icon library by just declaring it (Show & Hide).
Confirmation Modals — Easy-to-integrate confirmation messages with flexible buttons.
Radio & Checkbox — Checkbox for multiselect and radio support too.
Super Fast Setup — Just plug, play, and render your form!

⚙️ Quick Installation

Use npm or yarn to install:

npm install --save react-form-toaster
# or
yarn add react-form-toaster

🧩 How to Use It

1. Import and Setup

import Formbox from "react-form-toaster";
import "react-form-toaster/dist/dist/tailwind.css";

2. Basic User Form Example

import Formbox from "react-form-toaster";
import "react-form-toaster/dist/dist/tailwind.css";

<Formbox
  className={[
    "bg-gray-200 border-1 max-w-xl border-gray-100 rounded-lg shadow-md",
  ]}
  formtoogle={setfirstform}
  validationSchema={validationSchema}
  formtitle={[
    {
      title: "Form-Builder",
      className: ["text-2xl font-bold text-black "],
    },
  ]}
  textfield={[
    {
      name: "firstname",
      placeholder: "Enter your Firstname...",
      label: "FirstName",
      required: true,
      type: "text",
    },
    {
      name: "password",
      placeholder: "Enter your password...",
      label: "Password",
      type: "password",
      required: true,
      passwordToggle: true,
      icon: { show: Eye, hide: EyeOff },
    },
    {
      name: "search",
      placeholder: "Search your profession...",
      label: "Search",
      type: "search",
    },
    {
      name: "age",
      placeholder: "Enter your age...",
      label: "Age",
      type: "number",
      required: true,
    },
    {
      name: "marritalStatus?",
      label: "Marital Status",
      type: "checkbox",
      checklimit: 1,
      required: true,
      options: [
        { label: "Married", value: "married" },
        { label: "Unmarried", value: "unmarried" },
        { label: "other", value: "other" },
      ],
    },
    {
      name: "file",
      placeholder: "Upload your Image",
      label: "File",
      type: "file",
      arialabel: "File",
      maxFiles: 2,
      selectlabel: "Select File pdf or image",
      accept: ".pdf, image/*",
      className: [
        "border-2 border-dotted border-gray-400 p-2 rounded-lg bg-gray-100",
      ],
    },
  ]}
  buttons={[
    {
      name: "Reset Button",
      type: "reset",
      arialabel: "reset_button",
      tooltip: "Reset Button",
    },
    {
      name: "Submit",
      type: "submit",
      arialabel: "Submit_button",
      tooltip: "Submit Button",
      function: handlesubmit,
      loader: {
        loader: loader,
      },
    },
  ]}
  validationSchema={validationSchema}
/>

3. Submit Handler

const handlesubmit = (data: any, e: React.MouseEvent) => {
  e.preventDefault();
  console.log(data);
};

4. Zod Validation Schema

const validationSchema = z.object({
  firstname: z.string().min(4, { message: "First name must be at least 4 characters" }),
  age: z.number().min(18, { message: "You must be at least 18 years old" })
});

🔍 Overview of Main Component Props

`Formbox` Component

Prop	Description
`formtoogle`	Toggle function for form visibility
`formtitle`	Title array for form headings
`textfield`	Array of input field definitions
`buttons`	Submit, reset, or custom button configurations
`message`	Message block for confirmation dialogs
`validationSchema`	Zod schema for validation
`className`	Custom styles for layout and design

`TextField` Options

name, placeholder, label, type, required, arialabel, passwordToggle, icon, checklimit, options

File Upload Support

Add number, accept, selectlabel, className, maxFiles, and arialabel for custom file uploads.

Buttons

Add number, type, label, function, className, arialabel, tooltip, loader.

Control labels, click behavior, classes, and accessibility with full flexibility.

🙌 Join the Community

If you found this helpful, consider giving the GitHub repo a ⭐!

Contributions are always welcome — feel free to open issues, suggest improvements, or share your feedback to help make it even better.

React Form Toaster 1.0.0

Pawan Bisht — Mon, 28 Apr 2025 07:51:18 +0000

React-Form-Toaster

🎊 React-Form-Toaster is a powerful and flexible library designed for creating dynamic forms in React with ease. Users can quickly generate complex forms by simply defining input types, buttons, and other elements, without needing to create each element separately.

$ npm install --save react-form-toaster
$ yarn add react-form-toaster

Features

Easy Setup: Get started in less than 10 seconds! Quickly integrate and begin creating dynamic forms without hassle.😎
Dynamic Form Creation: Simply define the type of fields, labels, form title, and required attributes, and the library handles the rest.
Highly Customizable: Customize every aspect of your form, including classes, messages, and more, to fit your specific needs.
TypeScript Support: Built with TypeScript, ensuring strong typing and safer code development.🤯
Tailwind CSS Integration: Optimized for Tailwind CSS, allowing for efficient and modern styling right out of the box.
Default Form UI: Comes with a beautifully designed default form UI that you can use as-is or customize further to match your design requirements.
Form Validation and Error Handling: Easily define required fields and validate user input with built-in error handling and custom validation functions.🍃
Responsive Design: Fully responsive, making it easy to create forms that look great on any device.
Animation and Effects: Easily apply animations, such as click outside the box to close the form.
Fully Customizable Forms: Provides the flexibility to design forms with custom classes and styles, ensuring they match your application's theme.😱

Quick Setup

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App.tsx";
import "./index.css";
import reportWebVitals from "./reportWebVitals";
const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

Note: It is important to import index.css after App.tsx to ensure that all styles are correctly applied. This ensures that any global styles are loaded after the component has been imported.

User-Forms

import Formbox from "react-form-toaster";
import "react-form-toaster/dist/dist/tailwind.css";
<Formbox
  formtoogle={setfirstform}
  formtitle={[
    {
      title: "Form-Builder",
      className: ["text-2xl font-bold "],
    },
  ]}
  textfield={[
    {
      name: "firstname",
      placeholder: "Enter your Firstname",
      label: "FirstName",
      required: false,
      // type: "text"
    },
    {
      name: "age",
      placeholder: "Enter your age",
      label: "Age",
      type: "number",
    },
  ]}
  buttons={[
    {
      name: "Submit",
      type: "submit",
      label: "Submitbutton",
      function: handlesubmit,
    },
    {
      name: "Reset",
      type: "reset",
      label: "Submitbutton",
      function: handlesubmit,
    },
  ]}
/>;

const handlesubmit = (data: any, e: React.MouseEvent) => {
  e.preventDefault();
  console.log(data);
};

Confirmation-Forms

 <Formbox
 formtoogle={setsecondform}
 formtitle={[{
 title: "Confirmation-Form",
 }]}
 message={[{
 message: "This is very important file Are you sure want to delete this file? Please reconfirm it!"
 }]}
 buttons={[{
 name: "Ok",
 label: "Confirm",
 type: "ok",
 function: () => handleConfirm(true),
 className: ["bg-red-600"]
 },{
 name: "Cancel",
 label: "Cancel",
 type: "cancel",
 function: () => handleConfirm(false),
 className: ["text-red-600 border-1 border-red-600 bg-gray-100 hover:border-red-600 "]
 }]}
 />

const handleConfirm = (confirm: boolean) => {
  console.log(confirm, productId);
  if (confirm && productId) {
    console.log(" We got both of them. Hurrah! 🏆 ");
  }
  setsecondform(false);
};

Contribute

Show your ❤️ and support by giving a ⭐. Any suggestions are welcome! Take a look at the contributing guide.
You can also find me on Github 277pawan.

License

MIT

Free Library, Happy Coding😎😎!

REACT FORM TOASTER (1.1.1).

Pawan Bisht — Wed, 04 Sep 2024 17:06:46 +0000

React-Form-Toaster (1.1.1)

https://cure-ten.vercel.app/static/media/ezgif.com-video-to-gif-converter.01200ebb8d2078e8d60e.gif

$ npm install --save react-form-toaster
$ yarn add react-form-toaster

Features

Easy Setup: Get started in less than 10 seconds! Quickly integrate and begin creating dynamic forms without hassle.😎
Dynamic Form Creation: Simply define the type of fields, labels, form title, and required attributes, and the library handles the rest.
Highly Customizable: Customize every aspect of your form, including classes, messages, and more, to fit your specific needs.
TypeScript Support: Built with TypeScript, ensuring strong typing and safer code development.🤯
Tailwind CSS Integration: Optimized for Tailwind CSS, allowing for efficient and modern styling right out of the box.
Default Form UI: Comes with a beautifully designed default form UI that you can use as-is or customize further to match your design requirements.
Form Validation and Error Handling: Easily define required fields and validate user input with built-in error handling and custom validation functions.🍃
Responsive Design: Fully responsive, making it easy to create forms that look great on any device.
Zod Validation: Easily apply Zod validation in your Form🔐.
Fully Customizable Forms: Provides the flexibility to design forms with custom classes and styles, ensuring they match your application's theme.😱

Quick Setup

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App.tsx";
import "./index.css";
import reportWebVitals from "./reportWebVitals";
const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
);

Note: It is important to import index.css after App.tsx to ensure that all styles are correctly applied. This ensures that any global styles are loaded after the component has been imported.

User-Forms

import Formbox from "react-form-toaster";
import "react-form-toaster/dist/dist/tailwind.css";
<Formbox
  formtoogle={setfirstform}
  formtitle={[
    {
      title: "Form-Builder",
      className: ["text-2xl font-bold "],
    },
  ]}
  textfield={[
    {
      name: "firstname",
      placeholder: "Enter your Firstname",
      label: "FirstName",
      required: false,
      // type: "text"
    },
    {
      name: "age",
      placeholder: "Enter your age",
      label: "Age",
      type: "number",
    },
  ]}
  buttons={[
    {
      name: "Submit",
      type: "submit",
      label: "Submitbutton",
      function: handlesubmit,
    },
    {
      name: "Reset",
      type: "reset",
      label: "Submitbutton",
      function: handlesubmit,
    },
  ]}
  validationSchema={validationSchema}
/>;

const handlesubmit = (data: any, e: React.MouseEvent) => {
  e.preventDefault();
  console.log(data);
};

Zod Validation

const validationSchema = z.object({
  firstname: z
    .string()
    .min(4, { message: "First name must be at least 4 characters" }),
  age: z.number().min(18, { message: "You must be at least 18 years old" }),
});

Confirmation-Forms

 <Formbox
 formtoogle={setsecondform}
 formtitle={[{
 title: "Confirmation-Form",
 }]}
 message={[{
 message: "This is very important file Are you sure want to delete this file? Please reconfirm it!"
 }]}
 buttons={[{
 name: "Ok",
 label: "Confirm",
 type: "ok",
 function: () => handleConfirm(true),
 className: ["bg-red-600"]
 },{
 name: "Cancel",
 label: "Cancel",
 type: "cancel",
 function: () => handleConfirm(false,200),
 className: ["text-red-600 border-1 border-red-600 bg-gray-100 hover:border-red-600 "]
 }]}
 />

const handleConfirm = (confirm: boolean, productId: number) => {
  console.log(confirm, productId);
  if (confirm && productId) {
    console.log(" We got both of them. Hurrah! 🏆 ");
  }
  setsecondform(false);
};

Component Attributes

The following tables detail all available attributes for each component in React-Form-Toaster:

Formbox Component Attributes

Attribute	Type	Description	Required
`className`	string[]	Custom classes for the form container	No
`formtoogle`	Function	Function to toggle form visibility	Yes
`formtitle`	Object[]	Form title configuration	No
`textfield`	Object[]	Text input field configurations	No
`buttons`	Object[]	Button configurations	No
`message`	Object[]	Message configurations for confirmation forms	No
`validationSchema`	Object	Zod validation schema	No

TextField Component Attributes

Attribute	Type	Description	Example
`name`	string	Input field name	"firstname"
`placeholder`	string	Placeholder text	"Enter your Firstname..."
`label`	string	Label text	"FirstName"
`type`	string	Input type (text, number, file, etc.)	"number"
`required`	boolean	Whether field is required	true
`arialabel`	string	Accessibility label	"FileUpload"

File Upload Specific Attributes

Attribute	Type	Description	Example
`number`	number	Maximum number of files	5
`preview`	string	Preview type ("image")	"image"
`previewClassName`	string[]	Classes for preview element	["h-32 w-32"]
`icon`	JSX.Element	Icon for removing files	`<RiCloseLargeLine />`

Button Component Attributes

Attribute	Type	Description	Example
`name`	string	Button text	"Submit"
`type`	string	Button type (submit, reset, ok, cancel)	"submit"
`label`	string	ARIA label	"Submitbutton"
`function`	Function	Click handler	handlesubmit
`className`	string[]	Custom classes	["bg-red-600"]
`arialabel`	string	Accessibility label	"Submit_button"
`tooltip`	string	Tooltip text	"Submit Form"

Loader Component Attributes

Attribute	Type	Description	Example
`loader`	boolean	Whether to show loader	true
`className`	string[]	Loader custom classes	["border-red-500"]

Message Component Attributes

Attribute	Type	Description	Example
`message`	string	Message text	"Are you sure want to delete this file?"
`className`	string[]	Custom classes	["text-gray-700"]

Contribute

Show your ❤️ and support by giving a ⭐. Any suggestions are welcome! Take a look at the contributing guide.
You can also find me on Github 277pawan.

Free Library, Happy Coding😎😎!

DEV Community: Pawan Bisht

Your Database Backup Exists. But Can You Actually Restore It?

Your Database Backup Exists. But Can You Actually Restore It?

The backup paradox

A backup is not a recovery plan

Why manual restore testing doesn't happen often

Recovery time is part of the test

What should you test?

1. Connectivity

2. Schema

3. Data volume

4. Relationships

5. Critical queries

6. Data freshness

7. Indexes and other structural requirements

The important part: automate the boring work

Treat recovery testing like CI

Keep the application out of the restore test

Don't forget cleanup

Evidence matters

Start small

Can I connect?

Is the important data there?

Can I recover within my target?

The uncomfortable question

About Revenant

PostgreSQL Backup Isn’t Enough: How We Automated Restore Testing

Where we are today

PostgreSQL #OpenSource #DevOps #SRE #DisasterRecovery #GitHubActions #AWS #RDS #Database #CI #Infrastructure #Backup

I built Revenant to prove PostgreSQL backups actually restore — in CI, on AWS, without touching your app code.

React Hook Form vs Formik vs Schema-Driven Forms: Which Approach Should You Use?

React Hook Form

Formik

Schema-driven forms

So what's the difference?

When React Hook Form is a great choice

When Formik makes sense

When schema-driven forms make sense

React-Form-Toaster

Don't choose based only on popularity

A practical decision guide

Choose React Hook Form if:

Choose Formik if:

Choose schema-driven forms if:

Consider combining approaches if:

Final thoughts

React Form Toaster 2.0.9: What Changed and Why You Might Want to Try It

🚀 Install React Form Toaster

What makes it different?

🎨 Styling: Tailwind + Inline CSS

🔀 Conditional Fields

🔁 Repeatable Fields

🔔 Bring Your Own Toast Library

🌓 Inline or Modal

🧠 Why I'm Building This

📚 Documentation + Interactive Playground Coming Soon

🧪 An Interactive Playground

🤝 Contribute to React Form Toaster

❤️ Back the Project

Final Thoughts

🚀 React-Form-Toaster 1.1.3 is here. Build powerful forms in React/Next.js with ease, flexibility, and clean UX baked right in.

🚀 React-Form-Toaster 1.1.3

🔥 What's New in 1.1.3?

⚙️ Quick Installation

🧩 How to Use It

1. Import and Setup

2. Basic User Form Example

3. Submit Handler

4. Zod Validation Schema

🔍 Overview of Main Component Props

Formbox Component

TextField Options

File Upload Support

Buttons

🙌 Join the Community

React Form Toaster 1.0.0

React-Form-Toaster

Features

Quick Setup

User-Forms

`Formbox` Component

`TextField` Options