IFTTT

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the home automation and personal triggers I actually need instead of paying for IFTTT — and read the first paragraph before starting, because part of this is genuinely not replaceable.

Read this first. Two things here you cannot rebuild: integrations with consumer hardware that has no public API, and phone triggers that need an app on your phone — location, notifications, the physical buttons. For the hardware, the honest answer is Home Assistant, which talks to more devices than any commercial service and runs on a small box in your house. For the phone, it is a shortcuts app on the device itself. What this prompt builds is the glue between them and everything with a real API.

STACK
- Home Assistant on a small always-on machine for anything with a plug or a battery. Do not rewrite it
- Node 20+ with Fastify and SQLite through better-sqlite3 for the web-service side
- A worker process for schedules and polling
- Caddy in front, and the whole thing reachable only over a private network or a VPN unless a webhook genuinely needs to arrive from outside

THE DATA MODEL
- recipes: id, name, trigger_json, condition_json, actions_json, is_active, cooldown_seconds, created_at
- runs: id, recipe_id, trigger_payload_json, status, started_at, finished_at, error, dedupe_key
- step_runs: id, run_id, step_index, input_json, output_json, status, error, ms
- connections: id, service, credentials_encrypted, expires_at, refreshed_at, last_error
- cursors: id, source, value, updated_at — where a poller got to
- queue: id, run_id, run_at, attempts, locked_by, locked_at
- Every run and every step's payload stored. When a light comes on at three in the morning, the payload is the only thing that explains why

TRIGGERS
- Webhook with a secret, answering immediately and queueing
- Schedule with a cron expression and a time zone, daylight saving decided and tested
- Poll a feed or an API on an interval, with a cursor and deduplication by item identifier. A poller that re-emits everything after a restart is the classic disaster in this category
- An event from Home Assistant over its own API or an MQTT topic — which is how a door sensor, a button or a motion detector reaches this
- A location event from a phone, sent by the shortcuts app on the device as a webhook. That is the replacement for the app trigger, and it is one HTTP request

CONDITIONS
- Time of day, day of week, a state in Home Assistant, a value from a previous step, a cooldown since the last run
- Expressed as an explicit tree, never as evaluated code
- A cooldown per recipe, because a motion sensor will fire forty times and you want one message

ACTIONS
- Call a service in Home Assistant — lights, switches, thermostats, media
- HTTP request with full control and a retry policy
- Send a message: email, a push notification through a self-hosted notifier, a chat webhook
- Write a row, append to a file, run a small sandboxed script
- Branch, loop with a concurrency limit, delay, and stop with a reason

RELIABILITY
- Retries with exponential backoff and jitter, per step, with a maximum
- Idempotency keys for anything that has a side effect in the world. Sending a message twice is annoying; unlocking a door twice is not
- Deduplication on the trigger so a redelivered webhook runs once
- A dead-letter list with one-button replay
- The queue is a table with a lease, so a crashed worker's work is resumed rather than lost

SECURITY, WHICH IS DIFFERENT WHEN IT CONTROLS A HOUSE
- Nothing exposed to the internet that does not have to be. Prefer a VPN into the home network over an open port, always
- Any webhook that must be public carries a long secret in its path and a signature in its body, is rate-limited, and can only trigger recipes explicitly marked as externally triggerable
- Credentials encrypted at rest with a key from the environment
- Anything that unlocks, opens or disables something physical requires a confirmation step and is logged with the actor
- Assume the automation server will eventually be reachable by somebody you did not intend, and design so that the worst thing they can do is turn a lamp on

THE INTERFACE
- A recipe as a sentence: when this, if that, do these
- A run view with every step's payload
- A list of recipes with when each last ran and whether it worked
- Works on a phone, because that is where it will be checked

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, ENCRYPTION_KEY, HA_URL, HA_TOKEN, WEBHOOK_SECRET, SESSION_SECRET
- Migrations on boot, each once
- Old payloads pruned on a schedule with the retention stated
- Nightly backup off the machine, restore script — including Home Assistant's own configuration
- Health endpoint reporting queue depth and the age of every cursor

WHAT MATTERS MOST
Idempotency and the security boundary. Build the queue with leases and per-action idempotency keys first, then decide deliberately what is reachable from outside your own network. This is software that operates things in your house, and the failure modes are physical.

Give me the repository, migrations, .env.example, three seed recipes including one Home Assistant trigger and one phone webhook, and a README with deploy steps, the network layout, and a note on what stays with Home Assistant and why.