For a quick local test, I use the official Docker image. Run n8n on port 5678 and open the editor in a browser. That gets you a working UI and a feel for nodes and triggers in under five minutes.
For the first pass, I care about three things: secure access, persistence, and backups. Turn on basic auth or put n8n behind a reverse proxy with authentication. Set a proper encryption key for credentials. Do not rely on the default SQLite database for anything you care about. If you want persistence, run Postgres or another production-grade database and point n8n at it. Those three steps avoid the worst headaches later.
The environment comes down to scale and risk. For a hobby project or proof of concept, a single Docker container on a homelab server is fine. For anything long lived, I run n8n in Docker Compose with a Postgres container, or on a small VM with a managed Postgres instance.
If you plan on public webhooks, use a proper domain, TLS and a reverse proxy such as Nginx. Make sure the reverse proxy forwards the request and protocol headers so webhooks arrive intact. If you expect many concurrent executions, think about queue mode and worker processes. Start simple, measure load, then add workers when you see queueing.
Connecting to external services is mostly point-and-click. Create credentials in the n8n UI, then drop the right node into a workflow and attach those credentials. For services that use OAuth, follow the provider’s app setup and paste the client id and secret into n8n. For services that use API keys, treat those keys like passwords and store them in n8n’s credential store, encrypted by your encryption key.
A practical example: I make a workflow that receives an HTTP webhook, parses JSON, searches a Google Sheet and then posts a Slack message. The webhook node receives the POST, the Google Sheets node uses a service account, and the Slack node uses an incoming webhook URL. That is a complete automation that proves the pieces work together.
The trigger nodes are how workflows start: Webhook, Cron, IMAP, or third-party triggers. The Function node lets you run JavaScript for short custom logic. The SplitInBatches node helps when processing lists of items. Use error workflows to catch failed runs and notify you rather than losing the error in logs. Composite triggers are useful, but they can make state harder to follow. I keep the logic small and test each node in isolation. Export a workflow to JSON before making big changes so you can roll back quickly.
Troubleshooting is mostly a matter of checking the obvious. Look at n8n logs first. If a webhook does not trigger, check that the request reaches your host and that the response status is 2xx. If a node fails on authentication, re-enter credentials and test them in the credential settings. If a workflow behaves differently in production, compare environment variables and the database.
A common mistake is changing the encryption key after credentials are created; that will make existing credentials unreadable. If that happens, restore from a backup or re-create credentials.
Webhooks and custom nodes are the high-impact parts once the basics are in place. Webhooks are how real-time automation works. Use them to accept incoming data, validate the payload quickly, then push the job into a queue or a worker. If a provider needs a 200 response within a short timeout, accept and queue, then process asynchronously.
For custom nodes, n8n provides a node development path. You can scaffold a node with the recommended tooling, write TypeScript or JavaScript, and package it. I use a custom node when a service’s API is awkward or when I need a reusable wrapper. Keep custom nodes small and document the input and output fields so others can use them.
Use native nodes where they exist. For everything else, use HTTP request nodes and handle authentication at the credential level. For connectors that process many items, use pagination and handle rate limits. I also export important workflows and store them in Git as JSON; that gives a change history and an easy way to restore a previous working version. If multiple people touch the editor, use naming conventions for workflows and nodes so it is clear what each workflow does.
Name workflows clearly, use folders or tags to group related automations, and disable anything not actively used. Set executions to manual while testing. Use test credentials that operate in a sandbox where possible. Monitor executions for slow nodes and high retry rates. If a workflow needs retries, add backoff and caps to avoid thrashing external services.
In production, I stick to a proper database, a strong encryption key, TLS, and automated backups of both the database and exported workflows. Test restores occasionally so the backups are real. Keep workflows small and single-purpose. Use an error workflow for alerts. Treat credentials like secrets and rotate them on a schedule. That cuts down the surprises when automations start running at scale.
This gives a practical path from a simple n8n setup to something reliable enough to leave running. Start with Docker and the editor, move to Postgres for persistence, lock down access, and add webhooks and custom nodes when you need them. Keep things small, test often, and back up before making changes.
