DEV Community: Alexander Schneider

Configuring Stripe for a European SaaS Startup: A Field Guide

Alexander Schneider — Tue, 09 Jun 2026 14:48:54 +0000

Most Stripe tutorials stop at "create a Checkout Session and listen for checkout.session.completed." That gets you a demo. It does not get you a billing system you can trust with real European customers, real SEPA debits, real VAT and real cancellations.

This guide collects the configuration decisions that actually bite once money flows. It is written from the perspective of an EU-incorporated SaaS selling subscriptions to both consumers and businesses, across EUR and USD. Every code sample is generic. Adapt the IDs and plan names to your own account.

The running theme: your Stripe Dashboard config and your webhook code are two halves of one system. When they drift apart, customers pay and get nothing, or cancel and keep access. Most of the work below is keeping the two halves in sync.

1. Treat the webhook as your source of truth

The browser redirect after Checkout is a UI convenience. It is not proof that money moved. A user can close the tab, lose connection or pay with a method that settles days later. The only reliable signal that a subscription exists and is paid is a verified webhook event.

So provisioning, plan changes, access revocation and dunning all hang off webhooks. Get this layer right and the rest is configuration.

Verify every signature

Never trust a webhook body you have not verified. Stripe signs each delivery with your endpoint secret.

import Stripe from 'stripe'

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY)

export async function handleWebhook(request) {
  const signature = request.headers.get('stripe-signature')
  const body = await request.text() // raw body, not parsed JSON

  let event
  try {
    event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET
    )
  } catch (err) {
    return new Response('Invalid signature', { status: 400 })
  }

  // event is now trustworthy
}

Two gotchas that cost people hours:

Verify against the raw request body. If your framework parses JSON before you reach the handler, re-serializing it changes bytes and the signature check fails. Capture the raw body first.
On edge and serverless runtimes without Node's crypto, use constructEventAsync instead of constructEvent. It uses the Web Crypto API and returns a promise.

Subscribe to the events your code actually handles

Two failure modes, equally common. You subscribe to events your code ignores, so deliveries pile up as no-ops. Or your code handles events the Dashboard never sends, so a whole class of customers silently never gets provisioned. Audit both directions on a schedule.

For a subscription product, this is a sane baseline event set:

checkout.session.completed
checkout.session.async_payment_succeeded
checkout.session.async_payment_failed
checkout.session.expired
customer.subscription.created
customer.subscription.updated
customer.subscription.deleted
invoice.paid
invoice.payment_failed

Not every event in that list does the same kind of work. Separate them in your own head and in your code:

Provisioning events change account state and trigger email: the checkout completions, the subscription lifecycle, the invoice outcomes.
Tracking events feed analytics and observability only: expired sessions, failed async payments. They should return 200 quickly and do nothing else.

const PROVISIONING_EVENTS = new Set([
  'checkout.session.completed',
  'checkout.session.async_payment_succeeded',
  'customer.subscription.created',
  'customer.subscription.updated',
  'customer.subscription.deleted',
  'invoice.paid',
  'invoice.payment_failed',
])

const TRACKING_EVENTS = new Set([
  'checkout.session.expired',
  'checkout.session.async_payment_failed',
])

if (TRACKING_EVENTS.has(event.type)) {
  recordAnalytics(event)
  return ok() // no state change
}

if (!PROVISIONING_EVENTS.has(event.type)) {
  return ok() // unknown type, acknowledge and ignore
}

The reason to spell this out: when someone asks "should we add checkout.session.expired to the webhook," the honest answer is "yes, but only for analytics, it will not provision anyone." Mixing the two categories leads teams to over-prioritize harmless events and under-prioritize the one that actually loses revenue. More on that one next.

Make handlers idempotent

Stripe retries deliveries, and a single business action can arrive as several events. Store each processed event.id and skip duplicates, or make your write operations safe to repeat.

if (await alreadyProcessed(event.id)) return ok()
await provision(event)
await markProcessed(event.id)

Always return 2xx fast

Acknowledge within Stripe's timeout, then do slow work asynchronously. A handler that calls three downstream services inline will start timing out under load, and Stripe will retry, which multiplies your load exactly when you can least afford it. Acknowledge, enqueue, process.

2. Asynchronous payment methods change the rules

This is the single most overlooked thing for EU sellers, because the methods that cause it are the ones EU customers want.

Cards and wallets settle synchronously. The customer pays, Stripe knows immediately, checkout.session.completed arrives with payment_status: 'paid'. SEPA Direct Debit does not work that way. It can take days to confirm or fail. With SEPA enabled, checkout.session.completed can arrive with payment_status of unpaid or processing, and the real outcome comes later as a separate event.

If you provision on checkout.session.completed without checking payment_status, you hand out paid access for a debit that has not cleared and might bounce.

The correct pattern has two parts.

Guard the completion event:

if (event.type === 'checkout.session.completed') {
  const session = event.data.object
  if (session.payment_status !== 'paid') {
    // Delayed method such as SEPA. Do not provision yet.
    return ok()
  }
  await provision(session)
}

Provision on the async success event instead:

if (event.type === 'checkout.session.async_payment_succeeded') {
  await provision(event.data.object)
}

if (event.type === 'checkout.session.async_payment_failed') {
  await notifyPaymentFailed(event.data.object)
}

Here is the trap that catches teams who did the code right but the config wrong. If your handler is correct but checkout.session.async_payment_succeeded is not subscribed in the Dashboard, then a SEPA customer experiences this: they finish Checkout, the completion event is correctly skipped because it is not yet paid, the async success event fires when the debit clears, and your endpoint never receives it. They paid. They got nothing. No email, no access, no error anywhere you would notice. This is why the async success event is the highest-priority webhook to verify, not the flashy failure ones.

Keep your post-checkout page pending-neutral

Because the browser can return before settlement, the confirmation page must not assert that payment succeeded. Write copy that survives both outcomes:

Thanks. If your checkout completed successfully, we will activate your plan and email your access details shortly.

Avoid "Payment received, you now have access." For SEPA that can be false at the moment it renders. Drive the real "you are live" message from the webhook, by email, once settlement is confirmed. The redirect URL can carry a status flag for analytics, but treat that flag as a hint, never as authorization.

3. Resolve plans from data, never from display strings

Your webhook receives a price and needs to map it to an internal plan like hobby or professional. The mapping you choose determines how robust your billing is for the next three years, including for old prices you forgot about.

Stripe gives you several fields. Rank them by stability:

Price metadata you set deliberately, for example metadata.plan = "professional".
lookup_key, a stable handle you assign, for example professional_monthly.
The opaque price ID, useful only with an explicit lookup table.

function resolvePlan(price) {
  if (price.metadata?.plan) return price.metadata.plan
  if (price.lookup_key) return planFromLookupKey(price.lookup_key)

  // Last resort: an explicit, reviewed map of legacy IDs.
  return LEGACY_PRICE_TO_PLAN[price.id] ?? null
}

What not to do: parse the human-readable nickname or product name. Display strings drift, get localized and contain abbreviations. A regex that classifies plans from a nickname will eventually misfire.

A concrete example of how it misfires. Say you match whole words to be "safe":

// Looks careful. Is a landmine.
if (/\bprofessional\b/.test(text)) return 'professional'

A legacy price nicknamed api-pro-monthly contains pro, not professional, so this returns nothing and the active subscription syncs with no plan. Worse, a price nicknamed api-hobby-pro matches \bhobby\b first and resolves a Professional subscription as Hobby. Both bugs are invisible until a customer on that old price tries to manage their account.

The fix is boring and correct: assign lookup_key and metadata.plan to every price at creation, treat those as the contract and keep nicknames purely human. When you migrate prices, carry the same lookup_key forward.

Do not lean on `client_reference_id` alone

client_reference_id is handy for attribution, but Stripe can omit or drop it, and some setups only attach it for non-bot traffic. Use it as a fallback signal, not the primary key. For Payment Links, the link ID itself is a more stable plan hint than the reference string. Order your resolution: payment link or price first, metadata second, client_reference_id last.

4. Pricing across EUR and USD without confusing customers

European SaaS usually wants EUR as the primary currency and USD as an alternate, so US visitors see familiar numbers. Stripe supports multi-currency prices for exactly this. The mistake is letting your marketing copy and your Checkout disagree.

A common drift: the public pricing page is written in USD because the template came from a US example, say $29 and $299. The active EUR prices are €29 and €249. Now a German visitor reads $299, clicks, and Checkout charges €249. The Hobby tier happens to read 29 in both currencies, so nobody notices there, which makes the Professional mismatch even more confusing when a customer spots it.

None of this is a Stripe bug. It is a content decision you have to make on purpose:

Decide your primary currency and set every active price's alternate currencies to match it deliberately, not by Stripe's auto-conversion if you care about round numbers.
Make the public site reflect what a visitor in that region will actually be charged, or state the localization clearly.
Keep the number you advertise and the number Checkout shows reconcilable for every region you sell into.

Run a real Checkout from an EU IP and a US IP before launch and screenshot both. The amount on the page and the amount in Checkout should tell the same story.

5. Stripe Tax is not optional for EU sellers

Selling digital services into the EU means VAT, and VAT means rules that differ by customer type and country. Configure Stripe Tax early, because retrofitting tax onto live subscriptions is painful.

Turn on automatic tax and set it per price

const session = await stripe.checkout.sessions.create({
  mode: 'subscription',
  line_items: [{ price: 'price_...', quantity: 1 }],
  automatic_tax: { enabled: true },
  // collect what you need to compute and document VAT
  customer_update: { address: 'auto', name: 'auto' },
  tax_id_collection: { enabled: true },
})

tax_id_collection matters for B2B. A business customer in another EU country who provides a valid VAT ID triggers the reverse charge, so Stripe zero-rates the invoice and the customer self-accounts. Without VAT ID collection you charge them VAT they did not owe and they will ask for it back.

Register where you owe, then keep filing in view

Cross-border B2C digital sales in the EU fall under the One Stop Shop, which lets you file EU-wide through one registration once you pass the threshold. In your home country you may start as a small seller before you cross the local threshold. Stripe Tax tracks thresholds and flags locations that "need attention." Those flags are operational debt, not decoration. Calculating tax correctly at Checkout does not file it for you. Decide who owns filing and put it on a calendar.

Pick tax codes and tax behavior, then be consistent

Two settings drift without anyone deciding they should:

Tax code per product. SaaS for personal use and SaaS for business use can carry different codes. Assign them on purpose, not by accepting a default on the first product and forgetting on the second.
Tax behavior: inclusive or exclusive. A price can show tax as included in the displayed amount or added on top. If one tier is EUR-inclusive and another is EUR-exclusive, your invoices and your displayed prices stop being comparable across tiers. Pick one policy for a currency and apply it to every price in that currency, or document the exception loudly.

Put your VAT ID on every invoice, send finalized invoices and credit notes automatically and confirm invoice numbering is sequential. EU invoice law has formal requirements, and Stripe can satisfy them if you switch the settings on.

6. Configure the Customer Portal so it cannot strand a customer

The Customer Portal lets customers update payment methods, see invoices, switch plans and cancel without emailing you. It is also easy to misconfigure in ways that only show up when a customer tries something.

One portal configuration per product line

If you run more than one product on a single Stripe account, the default portal config can end up offering the wrong product's plans. Create a dedicated portal configuration per product line, restrict its eligible products and prices to that line and route each brand's "manage billing" link to the matching configuration. Then test each link end to end.

Decide downgrade timing on purpose

When a customer downgrades, do they lose the higher tier immediately or at the end of the period they already paid for? For most subscription businesses, downgrade at period end is the fair and expected behavior, because the customer paid through that date.

A sharp edge here: Stripe's period-end downgrade scheduling in the portal is documented for same-product price changes, for example monthly to yearly on one product. If your tiers are separate Stripe products rather than separate prices on one product, a cross-product change such as Professional down to Hobby may not behave as a clean period-end downgrade through the portal alone. Verify it with a live portal test in a test-mode account, and if it does not behave, handle that transition in your own backend by scheduling the swap for the period boundary. Do not assume the setting covers a case Stripe scoped more narrowly.

Proration, retention and redirects

Set proration behavior so plan changes bill the way you intend, and decide whether upgrades charge immediately.
A retention coupon offered at cancellation can recover real revenue. Wire the same coupon code into both the portal config and your own cancellation email so a customer sees one consistent offer.
Set the portal return URL to a real page on your site, and the terms and privacy links to your live legal pages.

7. Dunning: plan for payments that fail later

Cards expire. Debits bounce. Renewals fail. What happens next is a setting, and the defaults are not always what you want.

Smart Retries for failed card payments retries on Stripe's optimized schedule. Enable it and pick how aggressive.
Failure emails to the customer are toggled per category. The trap for EU sellers: the card-failure email is often on while the bank-debit failure email is off, even though SEPA is enabled. A failed SEPA debit then notifies no one. Turn on the communication for every method you actually accept.
After all retries, decide whether the subscription cancels, pauses or goes unpaid, and whether the invoice is marked uncollectible. Make this match how your access control reads subscription status.
Read the labels carefully. Stripe's retry settings sometimes name ACH Direct Debit specifically. If you accept SEPA and not ACH, confirm the SEPA-specific behavior rather than assuming the ACH setting applies to you.

Whatever you choose, the access decision in your app should be driven by webhook-delivered subscription status, so that "payment failed, retries exhausted, subscription canceled" actually removes access without a human in the loop.

8. Limit subscription sprawl

Two settings and one habit save you from confusing account states.

Limit customers to 1 subscription is off by default. With it off, the same customer can hold two active subscriptions at once, which makes "what plan is this account on" ambiguous. Turn it on unless you have a real reason to sell parallel subscriptions.

Payment Links also tend to create a fresh Customer per checkout, so the same email can map to several Stripe Customers over time. Your backend should match accounts by a stable key such as email plus subscription ID, and pick a deterministic rule for which subscription is authoritative when more than one exists. Decide that rule before you need it during an incident.

9. Price and product hygiene

Old prices do not disappear when you archive them. Subscriptions created on them keep billing on them. That is correct behavior, and it means every archived price with an active subscription is still part of your live billing surface.

Two practices keep this manageable:

Every active legacy price must still resolve to a current internal plan, through the metadata and lookup_key you assigned at creation, or through an explicit reviewed map. If a grandfathered price cannot resolve deterministically, downgrades and cancellations on it become guesswork. Migrate it or map it.
When you launch new prices, carry forward stable lookup_key values and metadata.plan so the resolver in section 3 keeps working without edits.

Audit archived-prices-with-active-subscriptions the same way you audit live ones. They charge real customers.

10. Security and keys

Billing is the worst place to be lax with credentials.

Never put a secret key in frontend or static code. Client code uses the publishable key only. If a secret key ever touches a repo, rotate it.
Prefer restricted keys scoped to what each service needs, over the account-wide secret key.
Store the webhook signing secret and the API key as platform secrets, not in committed config.

# example: set secrets out of band, never commit them
# most platforms have an equivalent (vercel env, fly secrets, wrangler secret, etc.)
your-platform secrets set STRIPE_SECRET_KEY=sk_live_...
your-platform secrets set STRIPE_WEBHOOK_SECRET=whsec_...

Rotate keys on a schedule and after any suspected exposure, and have a rotation runbook for the webhook secret so a rotation does not drop live deliveries.
Enforce two-factor for everyone with Dashboard access, and review team roles so support staff are not sitting on owner permissions.
Turn on Radar rules for card-testing protection. A public Checkout is a target for card-testing attacks, where someone runs stolen card numbers through your form. Set risk thresholds and alerting before you find out the hard way.

11. Coupons and promotion codes

Coupons are easy to create and easy to forget, and a forgotten one can be expensive.

Audit every coupon and promotion code periodically. The dangerous ones are internal test coupons, the 99% off forever you made during development and never deleted.
If a coupon should not reach customers, make sure it has no active promotion code that someone could type into Checkout. The coupon existing is fine. A live, enterable code attached to it is the risk.
For codes you do want live, set product restrictions, max redemptions, expiry and per-customer limits so a leaked code cannot drain a tier.

If your cancellation flow offers a retention discount, keep that promotion code's terms aligned with whatever your email and portal promise.

12. Branding, legal and invoices

The boring settings that make you look like a real company and keep you compliant.

Set the statement descriptor so customers recognize the charge on their bank statement and do not file a chargeback out of confusion.
Set a real support email, and your live terms and privacy URLs, in the public business details. EU sellers also need a reachable imprint.
Put your VAT ID on invoices, set sensible payment terms and enable PDF invoices and credit notes.
If you want a branded billing experience, configure a custom domain for Checkout, Payment Links and the Portal. If you do not, customers will see stripe.com domains, which is fine but worth deciding on rather than discovering.

13. Test the integration, not just the code

Stripe's test mode and CLI let you exercise the whole path without spending money. Use them on every webhook change.

stripe login

# forward live test events to your local handler
stripe listen --forward-to localhost:4242/api/webhooks/stripe

# fire specific events
stripe trigger checkout.session.completed
stripe trigger checkout.session.async_payment_succeeded
stripe trigger customer.subscription.deleted
stripe trigger invoice.payment_failed

Keep automated tests that assert your handler does the right thing for each event type you subscribe to, including the async success path that is hard to hit by clicking. When you add a new event in code, add it in the Dashboard and add a test in the same change, so the three never drift.

A pre-launch checklist

Run this before you take real EU money.

Webhooks

[ ] Signature verification on, against the raw body
[ ] Dashboard subscribed events match the events your code handles, both directions
[ ] checkout.session.async_payment_succeeded subscribed and provisioning
[ ] Handlers are idempotent and return 2xx fast

Async and Checkout

[ ] checkout.session.completed guarded on payment_status === 'paid'
[ ] Post-checkout page copy is pending-neutral
[ ] SEPA-paid test customer gets provisioned and emailed after settlement

Plans and prices

[ ] Every active price has lookup_key and metadata.plan
[ ] Plan resolution reads metadata and lookup key, never nicknames
[ ] Every archived price with active subscriptions resolves to a current plan

Currency and tax

[ ] Advertised prices reconcile with Checkout amounts per region
[ ] Automatic tax on, tax codes set per product, behavior consistent per currency
[ ] VAT ID collection on for B2B, reverse charge verified
[ ] Tax registration done where required, filing owner assigned

Portal and dunning

[ ] One portal config per product line, links routed correctly
[ ] Downgrade timing set, cross-product downgrades verified live
[ ] Failure emails on for every method you accept, including bank debit
[ ] After-retry behavior matches how your app reads subscription status

Hygiene and security

[ ] Limit customers to 1 subscription decided
[ ] No secret keys in client code, restricted keys where possible
[ ] Secrets stored out of band, rotation runbook exists, 2FA enforced
[ ] Radar card-testing protection on
[ ] Test and unused coupons restricted or deleted

The pattern under all of it is the same. Stripe is two systems, the Dashboard configuration and your webhook code, and they only work when they agree. Most billing bugs are not bugs in either half. They are a quiet disagreement between the two that no test caught because the test only checked one side.

Audit both halves together, on a schedule, and bill your European customers with a straight face.

How We Built a CTO-Grade Grafana Dashboard With Codex

Alexander Schneider — Sun, 31 May 2026 14:57:29 +0000

A good dashboard is not a wall of charts. It is an answer to a question.

For us, the question was simple:

Is production healthy, and if not, where should we look first?

We already had the usual observability ingredients: application metrics, host metrics, container metrics, structured logs, traces, synthetic checks, and database telemetry. The hard part was not collecting more data. The hard part was turning that data into a dashboard that a technical leader could open during a normal day, a deploy, or an incident and understand the state of the system quickly.

Grafana gave us the observability platform. Codex helped us keep the dashboard honest, small, tested, and aligned with the codebase.

This is the playbook we ended up with.

Start With Decisions, Not Charts

The first version of almost every dashboard grows by accumulation:

CPU chart
memory chart
request rate chart
latency chart
error chart
database chart
worker chart
logs chart
another latency chart

That is useful for exploration, but it is not a good top-level operational view.

For our CTO dashboard, we started from decisions:

Is the public API reachable?
Are enough API nodes alive to serve traffic redundantly?
Are workers alive and producing useful data?
Is PostgreSQL healthy?
Are alerts firing?
Is observability itself working?
If something is slow, is it API, worker, database, logs, or tracing?

Only after writing down those questions did we choose panels.

That one change made the dashboard much smaller.

Separate Product Health From Observability Coverage

One of the most important design choices was splitting these two ideas:

Product health: is the service working for users?
Observability coverage: can we see the service clearly?

Those are related, but they are not the same.

If an observability agent stops reporting from one host, that is bad. But it should not automatically make the product look down. Likewise, an API outage should not be hidden because the metrics pipeline is still green.

So our top-level dashboard has separate areas for:

production health
observability coverage
API node readiness
worker health
database health
alerts and drill-down links

This makes incidents easier to reason about. A broken monitoring path is visible, but it does not masquerade as a product outage.

Manage Grafana Assets Like Code

The biggest quality jump came when we stopped treating Grafana as a browser-only editing surface.

Our dashboards, alert rules, synthetic checks, and collector configs live in git:

ops/grafana/
  dashboards/
  alerts/
  synthetics/
  alloy/

This gives us normal engineering controls:

pull requests
code review
CI checks
repeatable sync
history
rollback

Dashboard JSON is not pretty, but it is still production behavior. If it decides what engineers see during incidents, it deserves the same review discipline as application code.

Grafana's MCP Is Actually Useful

One thing that surprised us in a good way: Grafana's MCP integration was not a toy.

It was practical enough to help with real dashboard work:

finding dashboards and panels
inspecting datasource-backed queries
checking alerting and dashboard structure
moving between Grafana context and repository context
turning operational questions into concrete dashboard changes

That matters because AI assistance gets much better when it can inspect the actual observability system instead of guessing from exported JSON alone. The Grafana MCP made Codex feel connected to the running operational surface, while the repository still stayed the source of truth.

We also tried similar MCP-style integrations from other observability vendors. In our evaluation, Grafana's was the most useful and reliable for day-to-day engineering work. Some alternatives, including New Relic's, did not feel mature enough for our workflow yet, so I would not recommend adopting them as the primary AI-observability interface today.

That may change, but if I were setting this up again now, I would start with Grafana.

Use Grafana Alloy as the Collection Layer

Grafana Alloy became the edge collector for our production telemetry.

In broad terms, the pipeline looks like this:

application metrics
host metrics
container metrics
database metrics
structured logs
OTLP traces
synthetic checks
        |
        v
Grafana Alloy
        |
        v
Grafana Cloud: Prometheus, Loki, Tempo, dashboards, alerts

Alloy lets us keep the collection profile explicit:

scrape host and container metrics
collect textfile metrics for custom worker state
forward structured logs
receive OTLP traces
remote-write metrics
apply relabeling and cardinality controls before data leaves the host

The important lesson: treat the collector config as part of the product. It defines what you can and cannot see during an incident.

Metrics For SLIs, Logs And Traces For Investigation

We try not to build core service-level indicators from log parsing.

For top-level API health, metrics are the right source:

rate(api_requests_total[5m])
rate(api_request_duration_seconds_bucket[5m])

Logs are still critical, but they are better for answering:

Which request failed?
Which worker cycle failed?
Which trace ID connects API, worker, and database behavior?
What did the application say at the time?

Traces are the next step after metrics and logs:

Which route was slow?
Where did time go?
Did the database dominate the request?
Was the problem isolated to one worker or one dependency?

The top-level dashboard should point to those tools. It should not try to replace them.

Add Domain Metrics, Not Just Infrastructure Metrics

Infrastructure metrics tell you whether machines are alive.

They do not always tell you whether the business process is useful.

For worker systems, we added domain-specific metrics such as:

worker alive
heartbeat age
last cycle status
last cycle duration
items produced in the latest cycle
items observed over recent windows
consecutive failures

This matters because a worker can be technically alive and still produce no useful output.

That distinction changed the quality of our alerts. We could alert on:

the worker is alive, but it has produced no useful data for a while

That is much better than only alerting when the process is dead.

Be Ruthless About Metric Semantics

One small example: we had a non-scraper background worker showing up in a "mentions produced" panel with a value of zero.

Technically, the metric existed.

Operationally, it was noise.

The fix was not to hide the worker everywhere. Its status and duration still mattered. The correct fix was to exclude it only from panels where "mentions" was the business meaning.

That is the kind of dashboard maintenance Codex is very good at:

inspect the dashboard JSON
find the PromQL targets
understand which panels use which metric
make the smallest scoped change
add a regression test

Small semantic fixes like this are what make dashboards feel trustworthy.

Test The Dashboard

Testing dashboards sounds strange until the first time a dashboard breaks during an incident.

We test things like:

dashboard JSON is valid
dashboard titles and UIDs stay stable
required panels exist
important PromQL expressions are still present
alert rule groups keep stable identifiers
datasource UIDs are correct
high-cardinality labels do not leak into metrics or logs
business panels exclude irrelevant worker types

The tests do not need to render the dashboard. They need to protect the contract.

Example contract:

assert "worker_type" in query
assert "analytics_rollup" not in mention_panel_series

In practice, the real tests are a little more robust than this, but the idea is simple: encode the intent.

Where Codex Helped Most

Codex was useful because it could work across the repo, not just inside one file.

A dashboard change often touches several places:

dashboard JSON
alert YAML
collector config
metric writer script
tests
docs
deployment sync logic

Codex could inspect those relationships and avoid local-only fixes that looked correct but broke the wider system.

The best workflow was:

state the operational problem in plain language
ask Codex to inspect the relevant repo paths
require a small scoped diff
require tests
review the PromQL and dashboard semantics like production code

Codex is not a replacement for operational judgment. It is a very fast assistant for applying that judgment consistently.

The Dashboard Architecture We Recommend

For a production service, I would structure Grafana like this:

1. CTO Overview

The top-level dashboard should answer:

is production healthy?
are users affected?
are alerts firing?
are enough nodes serving traffic?
are workers producing useful output?
is the database healthy?
is observability coverage intact?

Keep this dashboard short.

2. Production Infrastructure

This is where you put:

host CPU and memory
container CPU and memory
disk usage
process freshness
container freshness
agent health

3. Database Performance

This is where you put:

connection usage
cache hit ratio
lock pressure
transaction rate
temp file churn
slow query groups
table pressure
top query fingerprints

4. Tracing

This is where you put:

accepted spans
failed exports
slow API traces
recent worker traces
database spans

5. Synthetic Monitoring

This is where you put:

public liveness
readiness
deeper health checks
multi-region latency

The overview links to the diagnostic dashboards. It does not try to become all of them.

Security And Cardinality Rules

A public article should say this plainly: observability can leak data if you are careless.

Our rules:

never put API keys in labels
never put customer identifiers in labels
never put raw URLs with query strings in labels
never put request IDs or trace IDs in Prometheus labels
keep secrets out of dashboard JSON
keep collector credentials outside git
use route templates instead of raw paths
prefer bounded enum labels
drop or avoid high-cardinality metrics before remote write

Logs and traces can contain richer context, but even there you should be deliberate. Query-time parsing is often safer than promoting every field to a label.

Practical Tips

Here are the rules I would reuse on any team.

Write The Dashboard Goal First

Before adding panels, write one sentence:

This dashboard exists to help us decide ...

If you cannot finish that sentence, you are probably building a chart collection, not a dashboard.

Use Boring Names

Panel names should be operationally obvious:

API 5xx Error Rate
API Nodes Ready
Workers Alive
PostgreSQL Connections
Worker Heartbeat Age

Avoid clever names. During incidents, nobody wants to decode poetry.

Prefer Fewer Panels

The best overview dashboard is the one people actually use.

If a panel does not change a decision, move it to a drill-down dashboard.

Add Links

Every top-level panel should have an obvious next place to go:

production overview
database dashboard
tracing dashboard
logs exploration
runbook

Test The Intent

Do not only test JSON validity.

Test the meaning:

this panel uses the API metrics datasource
this alert has a stable UID
this worker is excluded from this business metric
this latency alert has a traffic floor
this dashboard does not depend on a deprecated metric

Keep Manual Edits Temporary

Manual Grafana edits are great for exploration. They are not a source of truth.

Once the panel matters, export it, commit it, review it, and sync it from code.

What "Perfect" Means

The perfect dashboard is not the biggest dashboard.

It is the dashboard where every panel earns its place.

For us, that meant:

metrics for health
logs for detail
traces for causality
alerts tied to action
dashboards stored in git
tests that protect dashboard meaning
Codex helping us keep changes small and consistent

Grafana made the system visible. Codex helped us make that visibility maintainable. That combination turned observability from a collection of charts into an operational product.

How We Built a CTO-Grade Grafana Dashboard With Codex

Alexander Schneider — Sun, 31 May 2026 14:57:29 +0000

A good dashboard is not a wall of charts. It is an answer to a question.

For us, the question was simple:

Is production healthy, and if not, where should we look first?

Grafana gave us the observability platform. Codex helped us keep the dashboard honest, small, tested, and aligned with the codebase.

This is the playbook we ended up with.

Start With Decisions, Not Charts

The first version of almost every dashboard grows by accumulation:

CPU chart
memory chart
request rate chart
latency chart
error chart
database chart
worker chart
logs chart
another latency chart

That is useful for exploration, but it is not a good top-level operational view.

For our CTO dashboard, we started from decisions:

Is the public API reachable?
Are enough API nodes alive to serve traffic redundantly?
Are workers alive and producing useful data?
Is PostgreSQL healthy?
Are alerts firing?
Is observability itself working?
If something is slow, is it API, worker, database, logs, or tracing?

Only after writing down those questions did we choose panels.

That one change made the dashboard much smaller.

Separate Product Health From Observability Coverage

One of the most important design choices was splitting these two ideas:

Product health: is the service working for users?
Observability coverage: can we see the service clearly?

Those are related, but they are not the same.

So our top-level dashboard has separate areas for:

production health
observability coverage
API node readiness
worker health
database health
alerts and drill-down links

This makes incidents easier to reason about. A broken monitoring path is visible, but it does not masquerade as a product outage.

Manage Grafana Assets Like Code

The biggest quality jump came when we stopped treating Grafana as a browser-only editing surface.

Our dashboards, alert rules, synthetic checks, and collector configs live in git:

ops/grafana/
  dashboards/
  alerts/
  synthetics/
  alloy/

This gives us normal engineering controls:

pull requests
code review
CI checks
repeatable sync
history
rollback

Dashboard JSON is not pretty, but it is still production behavior. If it decides what engineers see during incidents, it deserves the same review discipline as application code.

Grafana's MCP Is Actually Useful

One thing that surprised us in a good way: Grafana's MCP integration was not a toy.

It was practical enough to help with real dashboard work:

finding dashboards and panels
inspecting datasource-backed queries
checking alerting and dashboard structure
moving between Grafana context and repository context
turning operational questions into concrete dashboard changes

That may change, but if I were setting this up again now, I would start with Grafana.

Use Grafana Alloy as the Collection Layer

Grafana Alloy became the edge collector for our production telemetry.

In broad terms, the pipeline looks like this:

application metrics
host metrics
container metrics
database metrics
structured logs
OTLP traces
synthetic checks
        |
        v
Grafana Alloy
        |
        v
Grafana Cloud: Prometheus, Loki, Tempo, dashboards, alerts

Alloy lets us keep the collection profile explicit:

scrape host and container metrics
collect textfile metrics for custom worker state
forward structured logs
receive OTLP traces
remote-write metrics
apply relabeling and cardinality controls before data leaves the host

The important lesson: treat the collector config as part of the product. It defines what you can and cannot see during an incident.

Metrics For SLIs, Logs And Traces For Investigation

We try not to build core service-level indicators from log parsing.

For top-level API health, metrics are the right source:

rate(api_requests_total[5m])
rate(api_request_duration_seconds_bucket[5m])

Logs are still critical, but they are better for answering:

Which request failed?
Which worker cycle failed?
Which trace ID connects API, worker, and database behavior?
What did the application say at the time?

Traces are the next step after metrics and logs:

Which route was slow?
Where did time go?
Did the database dominate the request?
Was the problem isolated to one worker or one dependency?

The top-level dashboard should point to those tools. It should not try to replace them.

Add Domain Metrics, Not Just Infrastructure Metrics

Infrastructure metrics tell you whether machines are alive.

They do not always tell you whether the business process is useful.

For worker systems, we added domain-specific metrics such as:

worker alive
heartbeat age
last cycle status
last cycle duration
items produced in the latest cycle
items observed over recent windows
consecutive failures

This matters because a worker can be technically alive and still produce no useful output.

That distinction changed the quality of our alerts. We could alert on:

the worker is alive, but it has produced no useful data for a while

That is much better than only alerting when the process is dead.

Be Ruthless About Metric Semantics

One small example: we had a non-scraper background worker showing up in a "mentions produced" panel with a value of zero.

Technically, the metric existed.

Operationally, it was noise.

The fix was not to hide the worker everywhere. Its status and duration still mattered. The correct fix was to exclude it only from panels where "mentions" was the business meaning.

That is the kind of dashboard maintenance Codex is very good at:

inspect the dashboard JSON
find the PromQL targets
understand which panels use which metric
make the smallest scoped change
add a regression test

Small semantic fixes like this are what make dashboards feel trustworthy.

Test The Dashboard

Testing dashboards sounds strange until the first time a dashboard breaks during an incident.

We test things like:

dashboard JSON is valid
dashboard titles and UIDs stay stable
required panels exist
important PromQL expressions are still present
alert rule groups keep stable identifiers
datasource UIDs are correct
high-cardinality labels do not leak into metrics or logs
business panels exclude irrelevant worker types

The tests do not need to render the dashboard. They need to protect the contract.

Example contract:

assert "worker_type" in query
assert "analytics_rollup" not in mention_panel_series

In practice, the real tests are a little more robust than this, but the idea is simple: encode the intent.

Where Codex Helped Most

Codex was useful because it could work across the repo, not just inside one file.

A dashboard change often touches several places:

dashboard JSON
alert YAML
collector config
metric writer script
tests
docs
deployment sync logic

Codex could inspect those relationships and avoid local-only fixes that looked correct but broke the wider system.

The best workflow was:

state the operational problem in plain language
ask Codex to inspect the relevant repo paths
require a small scoped diff
require tests
review the PromQL and dashboard semantics like production code

Codex is not a replacement for operational judgment. It is a very fast assistant for applying that judgment consistently.

The Dashboard Architecture We Recommend

For a production service, I would structure Grafana like this:

1. CTO Overview

The top-level dashboard should answer:

is production healthy?
are users affected?
are alerts firing?
are enough nodes serving traffic?
are workers producing useful output?
is the database healthy?
is observability coverage intact?

Keep this dashboard short.

2. Production Infrastructure

This is where you put:

host CPU and memory
container CPU and memory
disk usage
process freshness
container freshness
agent health

3. Database Performance

This is where you put:

connection usage
cache hit ratio
lock pressure
transaction rate
temp file churn
slow query groups
table pressure
top query fingerprints

4. Tracing

This is where you put:

accepted spans
failed exports
slow API traces
recent worker traces
database spans

5. Synthetic Monitoring

This is where you put:

public liveness
readiness
deeper health checks
multi-region latency

The overview links to the diagnostic dashboards. It does not try to become all of them.

Security And Cardinality Rules

A public article should say this plainly: observability can leak data if you are careless.

Our rules:

never put API keys in labels
never put customer identifiers in labels
never put raw URLs with query strings in labels
never put request IDs or trace IDs in Prometheus labels
keep secrets out of dashboard JSON
keep collector credentials outside git
use route templates instead of raw paths
prefer bounded enum labels
drop or avoid high-cardinality metrics before remote write

Logs and traces can contain richer context, but even there you should be deliberate. Query-time parsing is often safer than promoting every field to a label.

Practical Tips

Here are the rules I would reuse on any team.

Write The Dashboard Goal First

Before adding panels, write one sentence:

This dashboard exists to help us decide ...

If you cannot finish that sentence, you are probably building a chart collection, not a dashboard.

Use Boring Names

Panel names should be operationally obvious:

API 5xx Error Rate
API Nodes Ready
Workers Alive
PostgreSQL Connections
Worker Heartbeat Age

Avoid clever names. During incidents, nobody wants to decode poetry.

Prefer Fewer Panels

The best overview dashboard is the one people actually use.

If a panel does not change a decision, move it to a drill-down dashboard.

Add Links

Every top-level panel should have an obvious next place to go:

production overview
database dashboard
tracing dashboard
logs exploration
runbook

Test The Intent

Do not only test JSON validity.

Test the meaning:

this panel uses the API metrics datasource
this alert has a stable UID
this worker is excluded from this business metric
this latency alert has a traffic floor
this dashboard does not depend on a deprecated metric

Keep Manual Edits Temporary

Manual Grafana edits are great for exploration. They are not a source of truth.

Once the panel matters, export it, commit it, review it, and sync it from code.

What "Perfect" Means

The perfect dashboard is not the biggest dashboard.

It is the dashboard where every panel earns its place.

For us, that meant:

metrics for health
logs for detail
traces for causality
alerts tied to action
dashboards stored in git
tests that protect dashboard meaning
Codex helping us keep changes small and consistent

Grafana made the system visible. Codex helped us make that visibility maintainable. That combination turned observability from a collection of charts into an operational product.

How to Add a Sentiment Confirmation Layer to OpenAlgo with Python

Alexander Schneider — Wed, 18 Mar 2026 06:01:49 +0000

Most trading signals answer one question:

"Is there a setup?"

That is useful, but often incomplete.

A breakout can be technically valid and still fail because there is no real
attention behind it. A screener can return ten names that all look similar on
price, while only one of them is actually dominating discussion, news flow, or
prediction-market activity.

That is the gap I wanted to close with an OpenAlgo integration for the
Adanos Finance Sentiment API.

Adanos tracks stock-level attention and directional bias across:

Reddit
X.com
financial news
Polymarket

Instead of replacing OpenAlgo, the idea is to use Adanos as a
confirmation layer before execution.

Why this is useful for traders

OpenAlgo already gives you the execution and automation building blocks:

TradingView webhooks
ChartInk-driven workflows
Python strategies
broker routing and order execution

Adanos adds a second decision layer:

"Does this setup also have attention, bullish conviction, and multi-source support right now?"

That matters when you want to:

reject weak breakouts
rank multiple screener hits
avoid low-attention entries
combine technical setups with non-price signals

The integration model that makes sense

The cleanest way to integrate Adanos into OpenAlgo is not as a broker plugin.

It works much better as an external signal layer:

TradingView / ChartInk / Python strategy
        -> Adanos sentiment gate
        -> OpenAlgo order execution

That keeps responsibilities separate:

OpenAlgo stays the automation and execution engine
Adanos stays the sentiment intelligence layer

What data the gate uses

For each symbol, the gate pulls source-level detail from Adanos and computes a
small composite.

Useful fields:

buzz_score
bullish_pct
mentions or trade_count
trend

Useful derived metrics:

average_buzz
bullish_avg
conviction
source_alignment

That gives you trader-friendly filters like:

average_buzz >= 60
bullish_avg >= 55
block symbols where multiple sources are falling
prefer aligned sources over wide divergence

Architecture

Here is the basic flow for TradingView:

TradingView alert
  -> Python middleware
  -> Adanos API check
  -> OpenAlgo placeorder / placesmartorder

The same pattern works for ChartInk:

ChartInk screener
  -> Python filter
  -> Adanos ranking / sentiment check
  -> OpenAlgo order

And for native Python strategies:

strategy signal
  -> Adanos source fetch
  -> local composite decision
  -> OpenAlgo execution

A small Python sentiment gate

This example keeps the execution path untouched and only decides whether an
order should be sent:

signals = get_source_signals(symbol)
composite = build_composite(signals)

if composite["average_buzz"] < 60:
    return "BLOCK"

if composite["bullish_avg"] < 55:
    return "BLOCK"

if composite["falling_sources"] >= 2:
    return "BLOCK"

return "PASS"

The full working example I built for OpenAlgo does a bit more:

fetches Reddit, X.com, News, and Polymarket signals
handles nullable or partially missing source data safely
computes average_buzz, bullish_avg, conviction, and source_alignment
supports both placeorder and placesmartorder
defaults to dry-run mode

Important implementation details

There are a few things worth getting right if you build this seriously.

1. Do not point alerts directly at OpenAlgo if you want sentiment gating

If your TradingView or ChartInk webhook still points straight to:

/api/v1/placeorder
or /api/v1/placesmartorder

then you are bypassing the sentiment layer entirely.

The webhook must point to your middleware or filter endpoint first.

2. Protect the middleware

This is not optional.

If you expose a public order-forwarding endpoint, it needs inbound verification:

secret header
token check
signature check
or another equivalent mechanism

Otherwise anyone who can reach that endpoint can try to trigger trades.

3. Keep payload contracts explicit

Do not hand-wave the OpenAlgo schema.

If you forward to placeorder, keep the documented structure intact:

apikey
strategy
symbol
action
exchange
quantity
pricetype
product

If you forward to placesmartorder, include the additional smart-order fields
that endpoint expects, such as position_size.

4. Normalize symbol inputs

If your source system sends {stock} and OpenAlgo expects symbol, normalize
that explicitly in middleware.

A lot of integration bugs are just field-name mismatches.

Coverage matters

Sentiment data is not equally strong for every symbol.

Before automating anything live, validate the names you actually trade.

A good workflow is:

test a few target symbols manually
set minimum thresholds for buzz and bullish ratio
decide what happens on low or partial coverage

That last point matters more than most people think. A robust workflow should
not crash just because one source is unavailable.

Why I still think this is a good integration

I originally proposed this as an upstream OpenAlgo documentation/examples PR.
The maintainers decided not to merge it because third-party sentiment APIs are
outside their current roadmap.

That is a fair scope decision.

But the integration pattern itself is still strong.

For OpenAlgo users, this is useful because it adds something their chart,
screener, or broker connection does not already provide:

cross-source attention
bullish ratio
trend confirmation
signal prioritization

That is exactly the kind of external intelligence layer traders can benefit
from without changing their existing execution stack.

If you want to build this yourself

Useful links:

Adanos API docs: https://api.adanos.org/docs
Get an API key: https://adanos.org/reddit-stock-sentiment#api
OpenAlgo: https://github.com/marketcalls/openalgo

Start small:

run a dry-run middleware
log approved and rejected trades
compare the gated results vs. your raw signal stream
only then wire it into live order flow

That is the fastest way to see whether sentiment confirmation improves your own process.

adanos-cli: Stock & Crypto Sentiment Straight From Your Terminal

Alexander Schneider — Fri, 06 Mar 2026 08:04:05 +0000

Retail traders check sentiment by tab-switching between Reddit, X, and news sites. There is no single view. adanos-cli is that single view.

What is adanos-cli?

adanos-cli is a Python CLI that queries the Adanos Finance Sentiment API. It aggregates mention counts, buzz scores, and sentiment polarity from four sources:

Reddit — 50+ stock and crypto subreddits (r/wallstreetbets, r/stocks, r/cryptocurrency, etc.)
X / Twitter — FinTwit tweet and reply analysis
Polymarket — prediction market prices, liquidity, and trade volume
Financial News — RSS-sourced article sentiment

pip install adanos-cli
adanos onboard wizard
adanos stock TSLA --days 7

The Interactive Shell

Run adanos without arguments to enter an interactive shell. Plain text is interpreted as a query:

adanos-cli> How does TSLA look this week?

The CLI parses intent, routes to the right endpoints, and returns a formatted report. It handles English and German, $TICKER syntax, crypto pairs like BTC/ETH, and "vs" comparisons.

A lightweight NLP module classifies input into nine intent types (stock report, crypto compare, trending scan, briefing, watchlist report, search fallback, etc.) with zero external dependencies.

Slash commands map directly to CLI features:

adanos-cli> /scan --asset stocks --style daytrader
adanos-cli> /trending --platform reddit-stocks --dimension sectors
adanos-cli> /briefing --profile investor --days 30

Morning Scan for Day Traders

adanos scan --asset stocks --style daytrader --limit 10

The scanner pulls trending data from all four platforms, merges by ticker, and computes a consensus buzz score, cross-platform sentiment, and confidence rating (0-99). Confidence weighs source diversity and mention volume.

Results carry a directional signal: bullish, bearish, neutral, or hot (high buzz, unclear direction). Drill into a ticker:

adanos stock NVDA --days 1

This returns a per-platform breakdown with Reddit mentions, X tweet volume, Polymarket contract prices, and news sentiment.

Crypto Portfolio Monitoring

Create a watchlist once, query it daily:

adanos watchlist add portfolio --asset crypto --symbols BTC,ETH,SOL,AVAX
adanos watchlist add portfolio --asset stocks --symbols MSTR,COIN
adanos watchlist report portfolio --asset all --days 7

Watchlists live in ~/.config/adanos-cli/watchlists.json and plug into the briefing command:

adanos briefing --from-watchlist portfolio --days 1

Briefings show top movers and sector heat, scoped to your assets. Seven profile presets (starter, daytrader, swing, investor, crypto, research, portfolio) control focus and depth.

Quick Comparisons

Side-by-side across platforms:

adanos compare --platform reddit-stocks TSLA,NVDA,AMD --days 7

Or natural language:

adanos ask "TSLA vs NVDA"
adanos ask "crypto BTC/ETH"

The parser detects vs and / patterns, resolves them to compare endpoints, and returns a unified table.

AI Agent Integration

Every command supports --output json. Errors go to stderr as structured JSON. stdout always contains parseable output.

adanos --output json capabilities
adanos --output json endpoint list
adanos --output json stock AAPL --days 7

Design choices for automation:

Exit codes: 0 success, 1 runtime error, 2 auth/usage error
31 endpoint IDs map 1:1 to the OpenAPI spec, callable via adanos endpoint call <id>
capabilities returns a self-describing JSON manifest (version, commands, auth setup, endpoint count)

Cron job piping the daily scan into Slack:

adanos --output json scan --asset stocks --style daytrader --limit 5 \
  | jq '{text: .rows[:3] | map(.ticker + " " + .signal) | join(", ")}' \
  | curl -X POST -H 'Content-Type: application/json' -d @- "$SLACK_WEBHOOK"

Research and Discovery

# Top stocks by Reddit mentions today
adanos trending --platform reddit-stocks --dimension main --days 1 --limit 20

# Sector-level sentiment
adanos trending --platform reddit-stocks --dimension sectors

# Country exposure
adanos trending --platform news-stocks --dimension countries

# Search across a platform
adanos search --platform x-stocks "Microsoft"

Check data freshness:

adanos health --platform all
adanos stats --platform reddit-stocks

Direct Endpoint Access

The CLI exposes all 31 API endpoints as callable IDs:

adanos endpoint list
adanos endpoint call reddit-stocks.trending --days 1 --limit 10
adanos endpoint call x-stocks.stock --ticker AAPL --days 7
adanos endpoint call polymarket-stocks.compare --tickers TSLA,NVDA

Every OpenAPI path is callable with no additional setup.

How the Sentiment Engine Works

The API runs a VADER + Twitter-RoBERTa ONNX ensemble:

VADER handles lexicon-based polarity with 55 custom finance terms (earnings language, momentum phrases, meme-stock slang)
Twitter-RoBERTa (quantized ONNX, 126 MB) covers informal social text that rule-based scoring misses

Scores blend at 40/60 VADER/RoBERTa weight with a ±0.14 neutral threshold.

The Buzz Score (0-100) rolls mention volume, sentiment strength, upvote quality, subreddit diversity, and trend direction into one number. A soft-cap function compresses the upper range so 85+ requires genuine multi-source attention.

Installation & Setup

pip install adanos-cli
# or
pipx install adanos-cli

# Guided setup
adanos onboard wizard

# Or set an existing key
adanos config set --api-key sk_live_xxx

Requires Python 3.10+. Config lives in ~/.config/adanos-cli/config.json. Environment variables (ADANOS_API_KEY, ADANOS_BASE_URL) and CLI flags override it.

Free tier: 250 requests/month.

Automate Accounting PDFs from Gmail to Google Drive (No Re-Imports, No Duplicates)

Alexander Schneider — Wed, 11 Feb 2026 12:53:02 +0000

If you do bookkeeping once a month, you’ve probably lived this loop:

invoices arrive via Gmail (sometimes forwarded, replied-to, or resent)
you download the PDFs
you store them in Drive
you file them during bookkeeping (move/delete/rename)
and then automation re-imports the same PDFs again 😩

This post shows a Google Apps Script setup that:

✅ scans your entire Gmail (excluding spam/trash)

✅ exports PDF attachments into Google Drive folders by month (YYYY-MM)

✅ detects duplicates by content hash (MD5)

✅ never re-imports the same email again—even if you move/delete files in Drive

✅ still labels threads in Gmail for visibility (but does not rely on labels for correctness)

The core idea

Relying on a Gmail thread label to skip work is tempting, but it breaks this common scenario:

A thread gets labeled “processed”… then later a new reply comes in with a new PDF attachment.

If you skip by label, you miss that PDF.

Instead, we do two things:

1) Message-ID tracking (stored in PropertiesService)

Every Gmail message is processed exactly once.
This is what prevents re-imports after you manually move/delete files.

2) MD5 de-duplication per month folder

Forwarded invoices and resent PDFs won’t create duplicates in Drive.

We still set a label (pdf-imported) for visibility, but the automation does not depend on it.

What you’ll get in Google Drive

A structure like this:

4_Gmail-Files/
  2026-02/
    2026-02-11__MESSAGEID__A0__Invoice_123.pdf
    2026-02-14__MESSAGEID__A0__Receipt.pdf
  2026-03/
    ...

You can do monthly bookkeeping and manually move/delete files however you like. The importer won’t recreate them.

Step 1: Create a Drive folder

Create a folder in Google Drive (e.g. 4_Gmail-Files) and copy its folder ID from the URL:

https://drive.google.com/drive/folders/<FOLDER_ID>

Step 2: Add the Apps Script

Go to script.google.com → New project → paste this code into Code.gs.

Replace ROOT_FOLDER_ID with your own folder ID.

/**
 * Gmail → PDF attachments → Google Drive monthly folders (YYYY-MM)
 *
 * ✅ scans ALL mail (in:anywhere), excluding spam/trash
 * ✅ catches new replies in old threads via LOOKBACK window
 * ✅ stores PDFs in <ROOT>/<YYYY-MM>/
 * ✅ prevents duplicates:
 *    - message-id tracking (each Gmail message processed once)
 *    - MD5 content de-dupe (identical PDFs per month folder stored once)
 * ✅ Gmail thread label for visibility (not used for skipping)
 */

const ROOT_FOLDER_ID = "PASTE_YOUR_FOLDER_ID_HERE";

// Lookback window: must be large enough to catch “old thread, new reply”
const LOOKBACK_DAYS = 365;

const GMAIL_QUERY =
  `in:anywhere -in:spam -in:trash newer_than:${LOOKBACK_DAYS}d has:attachment filename:pdf`;

// Label threads where we actually saved at least one PDF (visibility only)
const THREAD_LABEL = "pdf-imported";

// Mark thread as read after saving something?
const MARK_THREAD_AS_READ = false;

// How many threads to process per run
const MAX_THREADS_PER_RUN = 50;

// Tracker sizing: large enough so you don’t “forget” processed messages
const MAX_TRACKED_MESSAGES = 30000;

// Must be >= LOOKBACK_DAYS (recommend bigger)
const KEEP_MESSAGE_IDS_DAYS = 900;

function run() {
  const root = DriveApp.getFolderById(ROOT_FOLDER_ID);
  const labelObj = THREAD_LABEL ? getOrCreateGmailLabel_(THREAD_LABEL) : null;

  const tracker = loadMessageTracker_();
  pruneMessageTracker_(tracker);

  const threads = GmailApp.search(GMAIL_QUERY, 0, MAX_THREADS_PER_RUN);
  if (!threads.length) {
    saveMessageTracker_(tracker);
    return;
  }

  // monthKey -> { monthFolder, md5Set }
  const monthCache = new Map();

  for (const thread of threads) {
    const messages = thread.getMessages();
    let savedAnyInThread = false;

    for (const msg of messages) {
      const messageId = msg.getId();

      // Prevent re-imports even if files are moved/deleted in Drive
      if (tracker.ids[messageId]) continue;

      const msgDate = msg.getDate();
      const monthKey = formatMonthKey_(msgDate);
      const { monthFolder, md5Set } = getMonthContext_(root, monthKey, monthCache);

      const attachments = msg.getAttachments({ includeInlineImages: false });

      for (let i = 0; i < attachments.length; i++) {
        const att = attachments[i];

        const originalName = att.getName() || `attachment_${i}.pdf`;
        const isPdf =
          att.getContentType() === "application/pdf" ||
          originalName.toLowerCase().endsWith(".pdf");
        if (!isPdf) continue;

        const blob = att.copyBlob();
        const md5 = md5Hex_(blob);

        // Content de-dupe in the month folder
        if (md5Set.has(md5)) continue;

        const safeName = sanitizeFilename_(originalName);
        const datePrefix = Utilities.formatDate(
          msgDate,
          Session.getScriptTimeZone(),
          "yyyy-MM-dd"
        );

        const uniqueDriveName = `${datePrefix}__${messageId}__A${i}__${safeName}`;

        monthFolder.createFile(blob).setName(uniqueDriveName);
        md5Set.add(md5);

        savedAnyInThread = true;
      }

      // Mark this Gmail message as processed (even if it had no PDFs)
      tracker.ids[messageId] = Date.now();
      tracker.order.push(messageId);
    }

    if (savedAnyInThread) {
      if (labelObj) thread.addLabel(labelObj);
      if (MARK_THREAD_AS_READ) thread.markRead();
    }
  }

  saveMessageTracker_(tracker);
}

// ===== Tracker (PropertiesService) =====

function loadMessageTracker_() {
  const props = PropertiesService.getUserProperties();
  const raw = props.getProperty("PDF_TRACKER_V1");
  if (!raw) return { ids: {}, order: [] };

  try {
    const obj = JSON.parse(raw);
    if (!obj.ids) obj.ids = {};
    if (!obj.order) obj.order = [];
    return obj;
  } catch (e) {
    return { ids: {}, order: [] };
  }
}

function saveMessageTracker_(tracker) {
  pruneMessageTracker_(tracker);
  PropertiesService.getUserProperties().setProperty("PDF_TRACKER_V1", JSON.stringify(tracker));
}

function pruneMessageTracker_(tracker) {
  const cutoff = Date.now() - KEEP_MESSAGE_IDS_DAYS * 24 * 60 * 60 * 1000;

  const newOrder = [];
  for (const id of tracker.order) {
    const ts = tracker.ids[id];
    if (!ts) continue;
    if (ts >= cutoff) newOrder.push(id);
    else delete tracker.ids[id];
  }
  tracker.order = newOrder;

  if (tracker.order.length > MAX_TRACKED_MESSAGES) {
    const removeCount = tracker.order.length - MAX_TRACKED_MESSAGES;
    for (let i = 0; i < removeCount; i++) {
      const id = tracker.order[i];
      delete tracker.ids[id];
    }
    tracker.order = tracker.order.slice(removeCount);
  }
}

// ===== Month context + MD5 =====

function getMonthContext_(rootFolder, monthKey, monthCache) {
  if (monthCache.has(monthKey)) return monthCache.get(monthKey);

  const monthFolder = getOrCreateSubfolder_(rootFolder, monthKey);

  const md5Set = new Set();
  const files = monthFolder.getFiles();
  while (files.hasNext()) {
    const f = files.next();
    const md5 = f.getMd5Checksum();
    if (md5) md5Set.add(String(md5).toLowerCase());
  }

  const ctx = { monthFolder, md5Set };
  monthCache.set(monthKey, ctx);
  return ctx;
}

function md5Hex_(blob) {
  const bytes = blob.getBytes();
  const digest = Utilities.computeDigest(Utilities.DigestAlgorithm.MD5, bytes);
  return digest
    .map(b => {
      const v = (b < 0 ? b + 256 : b);
      return (v < 16 ? "0" : "") + v.toString(16);
    })
    .join("");
}

// ===== Helpers =====

function formatMonthKey_(dateObj) {
  return Utilities.formatDate(dateObj, Session.getScriptTimeZone(), "yyyy-MM");
}

function getOrCreateSubfolder_(parentFolder, name) {
  const it = parentFolder.getFoldersByName(name);
  if (it.hasNext()) return it.next();
  return parentFolder.createFolder(name);
}

function sanitizeFilename_(name) {
  return String(name)
    .replace(/[\/\:*?"<>|]/g, "_")
    .replace(/\s+/g, " ")
    .trim();
}

function getOrCreateGmailLabel_(labelName) {
  let label = GmailApp.getUserLabelByName(labelName);
  if (!label) label = GmailApp.createLabel(labelName);
  return label;
}

Step 3: Authorize the script

In Apps Script:

1) Select function run

2) Click Run

3) Accept permissions (Gmail read + Drive access)

Step 4: Set a trigger (every 6 hours)

1) Click the clock icon (“Triggers”)

2) Add Trigger:

Function: run
Event source: Time-driven
Type: Hour timer
Interval: Every 6 hours

Why this works for monthly bookkeeping

When you do bookkeeping, you’ll usually move/delete/rename PDFs inside the month folder.

This automation doesn’t care what happens in Drive afterward.

It remembers processed Gmail message IDs.
So the same email is never imported again, even if you remove the stored PDF.
And it still catches new PDFs posted later in an old thread.

Tuning tips

If you get invoices as replies to very old threads, increase LOOKBACK_DAYS.
Always keep KEEP_MESSAGE_IDS_DAYS >= LOOKBACK_DAYS (recommended: much bigger).
If you have high email volume, increase MAX_THREADS_PER_RUN (and keep an eye on Apps Script quotas).

Happy automating 👋

We Built Free Embeddable Stock Sentiment Widgets — Here's How to Use Them

Alexander Schneider — Mon, 09 Feb 2026 10:51:22 +0000

We just shipped something we're really excited about: three embeddable stock sentiment widgets that any developer can drop into their site with a single <script> tag.

No API key. No framework dependency. No build step. Just HTML.

Why We Built This

We run the Reddit Stock Sentiment API — it tracks what retail investors are talking about on Reddit and X/Twitter in real-time, scoring stocks by buzz, sentiment, and trend direction.

The API is great for developers building dashboards and trading tools. But we kept hearing the same request: "Can I just embed a widget on my blog?"

So we built exactly that.

The Three Widgets

1. Ticker Tape

A scrolling horizontal bar showing trending stocks with sentiment indicators. Think Bloomberg terminal vibes for your website header.

<script src="https://adanos.org/embed/adanos-widgets.js"></script>
<adanos-ticker-tape theme="dark" source="reddit" limit="15" speed="normal"></adanos-ticker-tape>

Each ticker item shows the stock logo, symbol, buzz score, a colored sentiment dot (green = bullish, red = bearish), and trend direction.

Attributes:
| Attribute | Options | Default |
|-----------|---------|---------|
| theme | light, dark | light |
| source | reddit, x | reddit |
| limit | 5, 10, 15, 20 | 10 |
| speed | slow, normal, fast | normal |

2. Top Movers

A ranked leaderboard of the hottest stocks. Shows buzz score, bullish percentage, trend direction, and a 7-day sparkline chart.

<script src="https://adanos.org/embed/adanos-widgets.js"></script>
<adanos-top-movers theme="light" source="reddit" limit="10" period="1" show-logos="true"></adanos-top-movers>

The table is fully responsive — company names hide on tablets, sparklines hide on phones.

Attributes:
| Attribute | Options | Default |
|-----------|---------|---------|
| theme | light, dark | light |
| source | reddit, x | reddit |
| limit | 5, 10, 15 | 10 |
| period | 1, 3, 7, 14, 21, 30 (days) | 1 |
| show-logos | true, false | true |

3. Stock Sentiment Card

A deep-dive card for a single stock. Shows buzz score, bullish percentage, mention count, trend, a 7-day sparkline, and an optional AI-generated explanation of why the stock is trending.

<script src="https://adanos.org/embed/adanos-widgets.js"></script>
<adanos-stock-sentiment ticker="TSLA" theme="light" source="reddit" show-explanation="true"></adanos-stock-sentiment>

Perfect for embedding in stock analysis articles.

Attributes:
| Attribute | Options | Default |
|-----------|---------|---------|
| theme | light, dark | light |
| source | reddit, x | reddit |
| ticker | Any stock symbol | (required) |
| show-explanation | true, false | true |

Technical Decisions

A few things we think fellow devs will appreciate:

Standard Web Components

No React. No Vue. No Angular. Just customElements.define() and Shadow DOM. The widgets work everywhere — static sites, WordPress, Next.js, whatever. If the browser supports Web Components (all modern ones do), it works.

Shadow DOM Encapsulation

Every widget uses Shadow DOM, so our styles never leak into your page and your styles never break our widgets. You get clean isolation out of the box.

No API Key Required

The widgets call our proxy endpoint which handles authentication server-side. You don't need to sign up, manage keys, or worry about exposing credentials in your frontend code.

Built-in Caching

Every widget has an in-memory cache with a 5-minute TTL and request deduplication. Drop five widgets on a page — they share cached responses. No redundant API calls.

Zero External Dependencies

The entire widget library is a single vanilla JS file. No npm packages, no bundler required, no polyfills. The font loading (Space Grotesk + JetBrains Mono) is handled internally and only triggers once per page.

Real-World Examples

Financial news site header:

<adanos-ticker-tape theme="dark" source="reddit" limit="20" speed="fast"></adanos-ticker-tape>

Weekly stock roundup blog post:

<adanos-top-movers period="7" limit="10" show-logos="true"></adanos-top-movers>

Single stock analysis article:

<adanos-stock-sentiment ticker="NVDA" show-explanation="true"></adanos-stock-sentiment>

Dark-themed trading dashboard:

<adanos-ticker-tape theme="dark" source="x"></adanos-ticker-tape>
<adanos-top-movers theme="dark" source="x" period="1"></adanos-top-movers>
<adanos-stock-sentiment ticker="AAPL" theme="dark" source="x"></adanos-stock-sentiment>

Try the Live Configurator

We built an interactive configurator where you can tweak every attribute, see a live preview, and copy the embed code:

adanos.org/widgets

Change the theme, data source, number of tickers, time period — the preview updates instantly and the embed code regenerates automatically.

What's Next

We're working on:

Custom color theming via CSS custom properties
Webhook-triggered updates for real-time push data
More data sources beyond Reddit and X

If you have ideas or feature requests, drop a comment below or reach out at adanos.org/contact.

Built by Adanos Software — we build trading intelligence tools for retail investors.

I built a Python script that alerts me when Reddit is hyping a stock

Alexander Schneider — Fri, 06 Feb 2026 10:14:11 +0000

GameStop went from $20 to $480. AMC from $2 to $72. Palantir doubled in a week.

Every single one started the same way: a handful of Reddit posts in r/wallstreetbets that snowballed into thousands of mentions within hours. By the time CNBC reported on it, the move was already happening.

The pattern is always the same:

A stock goes from ~5 mentions/day to 50+ mentions in a few hours
Sentiment flips heavily bullish (70%+ positive)
It spreads from one subreddit to multiple communities
The buzz score explodes

What if you could detect step 1 automatically and get a Slack message before step 4 happens?

That's what we're building.

What we're building

A Python script that:

Checks Reddit sentiment data every hour
Detects stocks with unusual buzz spikes (momentum)
Filters for high bullish sentiment (not just noise)
Sends you a Slack/Discord/email alert

No machine learning. No complex setup. Just API calls and simple thresholds.

Setup

pip install requests

You'll need a free API key from the Reddit Stock Sentiment API (250 requests/month, takes 30 seconds to sign up).

The detector — 40 lines of Python

# reddit_hype_alert.py
import requests
import json
from datetime import datetime

API_KEY = "your_api_key_here"
BASE = "https://api.adanos.org/reddit/stocks/v1"
HEADERS = {"X-API-Key": API_KEY}

# --- Thresholds (tune these to your preference) ---
BUZZ_MIN = 40            # Minimum buzz score to consider
BULLISH_MIN = 55         # Minimum bullish percentage
TREND_FILTER = "rising"  # Only alert on rising stocks
SPREAD_MIN = 3           # Mentioned in at least N subreddits

def get_trending():
    """Fetch top 50 trending stocks from the last 24 hours."""
    r = requests.get(f"{BASE}/trending", headers=HEADERS,
                     params={"limit": 50, "days": 1})
    r.raise_for_status()
    return r.json()

def detect_hype(stocks):
    """Filter for stocks showing hype signals."""
    alerts = []
    for s in stocks:
        if (s["buzz_score"] >= BUZZ_MIN
            and s.get("bullish_pct", 0) >= BULLISH_MIN
            and s["trend"] == TREND_FILTER
            and s.get("subreddit_count", 0) >= SPREAD_MIN):
            alerts.append(s)
    return alerts

def format_alert(stock):
    """Format a single stock alert."""
    return (
        f"🚨 ${stock['ticker']} — {stock.get('company_name', 'Unknown')}\n"
        f"   Buzz: {stock['buzz_score']:.1f}/100 ↑ {stock['trend']}\n"
        f"   Mentions: {stock['mentions']} across {stock.get('subreddit_count', '?')} subreddits\n"
        f"   Sentiment: {stock.get('bullish_pct', '?')}% bullish\n"
    )

# --- Run ---
print(f"[{datetime.now():%H:%M}] Scanning Reddit trending stocks...")
stocks = get_trending()
hype_stocks = detect_hype(stocks)

if hype_stocks:
    print(f"\n🔥 {len(hype_stocks)} stocks showing hype signals:\n")
    for s in hype_stocks:
        print(format_alert(s))
else:
    print("No hype signals detected right now.")

Run it:

$ python reddit_hype_alert.py

[14:30] Scanning Reddit trending stocks...

🔥 3 stocks showing hype signals:

🚨 $NVDA — NVIDIA Corporation
   Buzz: 92.3/100 ↑ rising
   Mentions: 487 across 12 subreddits
   Sentiment: 72% bullish

🚨 $PLTR — Palantir Technologies Inc.
   Buzz: 78.1/100 ↑ rising
   Mentions: 198 across 8 subreddits
   Sentiment: 68% bullish

🚨 $RKLB — Rocket Lab USA, Inc.
   Buzz: 54.2/100 ↑ rising
   Mentions: 67 across 5 subreddits
   Sentiment: 81% bullish

That third one — $RKLB with 67 mentions but 81% bullish across 5 subreddits — that's exactly the kind of early signal you want to catch. It's not yet on CNBC, but Reddit is already talking.

Add Slack notifications

Turn it into a real alert system with one function:

import os

SLACK_WEBHOOK = os.environ.get("SLACK_WEBHOOK_URL")

def send_slack_alert(hype_stocks):
    """Send hype alerts to Slack."""
    if not SLACK_WEBHOOK:
        return

    blocks = [{"type": "header", "text": {
        "type": "plain_text",
        "text": f"🔥 {len(hype_stocks)} Reddit Hype Alert{'s' if len(hype_stocks) > 1 else ''}"
    }}]

    for s in hype_stocks[:5]:
        blocks.append({"type": "section", "text": {"type": "mrkdwn", "text":
            f"*${s['ticker']}* — {s.get('company_name', '')}\n"
            f"Buzz `{s['buzz_score']:.1f}` · {s['mentions']} mentions · "
            f"{s.get('bullish_pct', '?')}% bullish · {s.get('subreddit_count', '?')} subreddits"
        }})

    requests.post(SLACK_WEBHOOK, json={"blocks": blocks})

# Update the run section:
if hype_stocks:
    send_slack_alert(hype_stocks)

Want an AI explanation of WHY it's trending?

The API has an /explain endpoint that uses an LLM to summarize what Reddit is actually saying:

def get_explanation(ticker):
    """Get AI-generated explanation of why a stock is trending."""
    r = requests.get(f"{BASE}/stock/{ticker}/explain", headers=HEADERS)
    if r.status_code == 200:
        return r.json().get("explanation", "")
    return None

# Add to your alert:
for s in hype_stocks:
    explanation = get_explanation(s["ticker"])
    if explanation:
        print(f"   💡 Why: {explanation}")

Output:

🚨 $RKLB — Rocket Lab USA, Inc.
   Buzz: 54.2/100 ↑ rising
   Mentions: 67 across 5 subreddits
   Sentiment: 81% bullish
   💡 Why: Rocket Lab trending after successful Neutron rocket test and new
   NASA contract announcement. Retail investors bullish on space sector growth.

Now you're not just seeing that something is trending — you know why.

Run it every hour with cron

# Edit crontab
crontab -e

# Add this line (runs every hour during market hours, Mon-Fri)
0 9-16 * * 1-5 cd /path/to/script && python reddit_hype_alert.py >> alerts.log 2>&1

Or if you prefer GitHub Actions, Docker, or a cloud function — the script is stateless, so it runs anywhere.

Tuning the thresholds

The default thresholds are conservative. Here's how to adjust them:

Signal	Conservative	Aggressive	What it catches
`BUZZ_MIN`	40	20	Lower = more alerts, earlier signals
`BULLISH_MIN`	55	40	Lower = includes mixed-sentiment stocks
`SPREAD_MIN`	3	1	Lower = catches single-subreddit hype
`TREND_FILTER`	`"rising"`	Remove filter	Also catches `"stable"` momentum

Start conservative. If you're getting 0-1 alerts per day, lower the thresholds. If you're getting 10+, raise them.

What I'd build next

Cross-platform validation: Check if the same stock is also trending on X/Twitter. Stocks hyped on both platforms have stronger signals.
Historical backtesting: Use the 90-day history (paid tier) to backtest which threshold combos would have caught past rallies.
Portfolio watchlist: Only alert on stocks you already own or are watching, using the /v1/stock/{ticker} endpoint.
Discord bot: Same logic, but posts to a Discord channel for your trading group.

Full code

The complete script is ~60 lines. It uses 2 API calls per run (trending + explain for each alert), so the free tier (250 requests/month) easily covers running it several times per day.

Reddit Stock Sentiment API — sign up for a free key
Full API docs
BuzzScore Whitepaper — how the 0-100 score works under the hood

Built by Adanos Software in Berlin. The API tracks 12,000+ tickers across 50+ subreddits, updated hourly.

How to Host Your Own n8n Automation Server on Hetzner Cloud for Less Than $6/Month

Alexander Schneider — Fri, 18 Jul 2025 07:00:17 +0000

If you're looking for a powerful automation platform that won't break the bank, self-hosting n8n on Hetzner Cloud might be the perfect solution. In this guide, I'll walk you through how we set up a production-ready n8n instance with enterprise-grade security for just ~$6.

Why Self-Host n8n?

n8n is an open-source workflow automation tool that rivals expensive solutions like Zapier or Make. By self-hosting, you get:

Complete data privacy and control
No workflow execution limits
Custom integrations and code
Full API access
Cost-effective scaling

The Setup: What We're Building

Here's what we'll deploy:

Server: Hetzner Cloud CX22 (2 vCPU, 4GB RAM)
Location: Falkenstein, Germany
Services: n8n (Docker), Caddy (reverse proxy with automatic SSL)
Security: UFW firewall, Fail2ban, audit logging, automated updates
Cost: ~$6 / month

Step 1: Creating the Hetzner Cloud Server

First, create a Hetzner Cloud account and set up a new server:

# Using Hetzner CLI (optional)
hcloud server create \
  --name n8n-server \
  --type cx22 \
  --image ubuntu-22.04 \
  --location fsn1 \
  --ssh-key ~/.ssh/id_rsa.pub

Pro tip: The CX22 instance type offers the best price-performance ratio for n8n. With 2 vCPUs and 4GB RAM, it can handle substantial workflows without issues.

Step 2: Initial Server Security Hardening

Security first! Here's our hardening checklist:

Create a non-root user

# As root
adduser admin
usermod -aG sudo admin
mkdir -p /home/admin/.ssh
cp ~/.ssh/authorized_keys /home/admin/.ssh/
chown -R admin:admin /home/admin/.ssh
chmod 700 /home/admin/.ssh
chmod 600 /home/admin/.ssh/authorized_keys

Disable root login and password authentication

# Edit SSH config
sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd

Set up UFW firewall

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable

Install and configure Fail2ban

apt update && apt install -y fail2ban
cat > /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
bantime = 2h
maxretry = 3
findtime = 10m

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
EOF

systemctl restart fail2ban

Enable automatic security updates

apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Set up audit logging

apt install -y auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
auditctl -w /etc/shadow -p wa -k shadow_changes
auditctl -w /var/log/auth.log -p wa -k auth_log
service auditd restart

Step 3: Installing Docker and Docker Compose

# Install Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

# Install Docker Compose
apt install -y docker-compose-plugin

# Verify installation
docker --version
docker compose version

Step 4: Setting Up n8n with Docker Compose

Create the n8n directory and docker-compose file:

mkdir -p /root/n8n
cd /root/n8n

Create a secure docker-compose.yml:

version: '3.8'

services:
  n8n:
    image: n8nio/n8n
    container_name: n8n
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"  # Only accessible locally
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - GENERIC_TIMEZONE=Europe/Berlin
    volumes:
      - n8n_data:/home/node/.n8n
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
      - /home/node/.n8n/cache

volumes:
  n8n_data:

Security insights:

Binding to 127.0.0.1 ensures n8n is only accessible through our reverse proxy
read_only: true prevents container filesystem modifications
no-new-privileges prevents privilege escalation
Using tmpfs for temporary files improves security and performance

Step 5: Setting Up Caddy as Reverse Proxy

Caddy provides automatic HTTPS certificates and is much simpler than nginx:

# Install Caddy
apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
apt update && apt install -y caddy

Configure Caddy:

cat > /etc/caddy/Caddyfile << 'EOF'
n8n.yourdomain.com {
    reverse_proxy localhost:5678 {
        header_up X-Real-IP {remote}
        header_up X-Forwarded-For {remote}
        header_up X-Forwarded-Proto {scheme}
    }

    # Security headers
    header {
        X-Content-Type-Options nosniff
        X-Frame-Options DENY
        X-XSS-Protection "1; mode=block"
        Referrer-Policy strict-origin-when-cross-origin
        -Server
    }

    # Enable compression
    encode gzip
}
EOF

systemctl restart caddy

Step 6: Starting n8n

cd /root/n8n
docker compose up -d

Visit https://n8n.yourdomain.com and complete the initial setup!

Advanced Security Measures

1. Implement IP-based access control

If you have a static IP, limit access to n8n:

n8n.yourdomain.com {
    @allowed {
        remote_ip 1.2.3.4 192.168.0.0/16
    }
    handle @allowed {
        reverse_proxy localhost:5678
    }
    handle {
        respond "Access Denied" 403
    }
}

2. Set up Fail2ban for n8n

Create a custom filter for failed n8n login attempts:

cat > /etc/fail2ban/filter.d/n8n-auth.conf << 'EOF'
[Definition]
failregex = ^.* 401 .* "POST /rest/auth/login.*" .*$
ignoreregex =
EOF

# Add to jail.local
cat >> /etc/fail2ban/jail.local << 'EOF'

[n8n-auth]
enabled = true
port = http,https
filter = n8n-auth
logpath = /var/log/caddy/access.log
maxretry = 5
bantime = 1h
EOF

3. Regular backups

Create a backup script:

#!/bin/bash
# /root/backup-n8n.sh
BACKUP_DIR="/root/backups"
mkdir -p $BACKUP_DIR
docker compose -f /root/n8n/docker-compose.yml down
docker run --rm -v n8n_data:/data -v $BACKUP_DIR:/backup alpine tar czf /backup/n8n-backup-$(date +%Y%m%d).tar.gz -C /data .
docker compose -f /root/n8n/docker-compose.yml up -d
# Keep only last 7 backups
find $BACKUP_DIR -name "n8n-backup-*.tar.gz" -mtime +7 -delete

Add to crontab:

0 3 * * * /root/backup-n8n.sh

Performance Optimization Tips

Enable Redis for scaling: Add a Redis container for better performance with multiple workers
Use external database: For production workloads, consider PostgreSQL instead of SQLite
Monitor resources: Install htop and set up monitoring with Prometheus/Grafana
Optimize workflows: Use webhook triggers instead of polling when possible

Cost Breakdown

Hetzner CX22 Server: ~$6/month
Domain (use a subdomain): ~$0/year
Total monthly cost: ~$6/month

Compare this to n8n Cloud's pricing starting at $20/month for just 2,500 workflow executions!

Lessons Learned

Start with security: It's easier to harden from the beginning than retrofit later
Docker adds complexity but worth it: Container isolation and easy updates outweigh the overhead
Caddy > Nginx for simple setups: Automatic HTTPS saves hours of configuration
Monitor everything: Set up alerts for disk space, CPU usage, and failed login attempts
Document everything: Future you will thank present you

Troubleshooting Common Issues

n8n won't start

# Check logs
docker logs n8n
# Common fix: permissions on data volume
docker volume rm n8n_data  # Warning: deletes data!

SSL certificate issues

# Caddy logs
journalctl -u caddy -f
# Force certificate renewal
caddy reload --config /etc/caddy/Caddyfile

High memory usage

# Add memory limits to docker-compose.yml
deploy:
  resources:
    limits:
      memory: 3g

Conclusion

For less than the price of a Netflix subscription, you can run your own powerful automation platform with complete control over your data. The setup takes about an hour, but the flexibility and cost savings make it worthwhile for anyone serious about automation.

Have you set up your own n8n instance? What challenges did you face? Let me know in the comments!

Resources:

Monitor Any Stock Price in Your App with 7 Lines of JavaScript

Alexander Schneider — Sun, 13 Jul 2025 07:35:55 +0000

Ever wanted to add stock price monitoring to your app? Maybe you're building a dashboard, a portfolio tracker, or just want to get notified when Tesla does something crazy again?

Here's how to add real-time stock monitoring to ANY JavaScript application using the StockAlert.pro API.

Installation

npm install @stockalert/sdk
# or
yarn add @stockalert/sdk

The 7-Line Version (I Wasn't Kidding)

import { StockAlertClient } from '@stockalert/sdk';

const client = new StockAlertClient({ apiKey: 'your-free-api-key' });

// Get notified when Apple hits $150
await client.alerts.create({
  symbol: 'AAPL',
  condition: 'price_above',
  threshold: 150
});

That's it. You'll get an email when Apple hits $150. But let's build something more useful...

Real-World Example: Portfolio Dashboard

Let's build a portfolio monitoring system that tracks multiple stocks and sends you notifications when it's time to take profits or cut losses.

import { StockAlertClient } from '@stockalert/sdk';

const client = new StockAlertClient({ apiKey: process.env.STOCKALERT_API_KEY });

// Your portfolio
const portfolio = [
  { symbol: 'AAPL', shares: 100, buyPrice: 145 },
  { symbol: 'GOOGL', shares: 50, buyPrice: 2800 },
  { symbol: 'MSFT', shares: 75, buyPrice: 380 }
];

// Set up price alerts for your portfolio
async function monitorPortfolio() {
  for (const position of portfolio) {
    // Alert when profit hits 10%
    await client.alerts.create({
      symbol: position.symbol,
      condition: 'price_change_up',
      threshold: 10  // 10% gain
    });

    // Alert when loss hits 5% (stop loss)
    await client.alerts.create({
      symbol: position.symbol,
      condition: 'price_change_down',
      threshold: 5  // 5% loss
    });

    console.log(`📊 Monitoring ${position.symbol}:`);
    console.log(`   Alert when up 10% from current price`);
    console.log(`   Alert when down 5% from current price`);
  }

  console.log('\n✅ All alerts created! You\'ll get emails when targets are hit.');
}

// Start monitoring
monitorPortfolio();

Working with Webhooks

Want to receive events in your app? Here's how to properly set up webhooks:

Pro tip: You can view and test all your webhooks at https://stockalert.pro/dashboard/settings

import crypto from 'crypto';

// Step 1: Register your webhook endpoint
const webhook = await client.webhooks.create({
  url: 'https://your-app.com/stockalert-webhook',
  events: ['alert.triggered']
});

console.log('Webhook secret:', webhook.secret); // Save this for verification!

// Step 2: Create alerts (they'll send emails/SMS by default)
const alert = await client.alerts.create({
  symbol: 'AAPL',
  condition: 'price_above',
  threshold: 150
});

// Step 3: Handle webhook events when alerts trigger
app.post('/stockalert-webhook', (req, res) => {
  const { event, timestamp, data } = req.body;

  // Verify webhook signature (recommended)
  const signature = req.headers['x-stockalert-signature'];
  const expectedSignature = crypto
    .createHmac('sha256', webhook.secret)
    .update(JSON.stringify(req.body))
    .digest('hex');

  if (signature !== expectedSignature) {
    return res.status(401).send('Invalid signature');
  }

  if (event === 'alert.triggered') {
    console.log(`🚨 Alert triggered at ${timestamp}`);
    console.log(`Symbol: ${data.symbol}`);
    console.log(`Condition: ${data.condition} (threshold: ${data.threshold})`);
    console.log(`Current value: $${data.current_value}`);

    // Your custom logic here: update database, send Slack message, etc.
  }

  res.json({ received: true });
});

Building a Price Monitoring Slack Bot

Here's a Slack bot that lets your team monitor stocks:

import { StockAlertClient } from '@stockalert/sdk';
import { WebClient } from '@slack/web-api';

const stockAlert = new StockAlertClient({ apiKey: process.env.STOCKALERT_API_KEY });
const slack = new WebClient(process.env.SLACK_TOKEN);

// Slack slash command: /watch AAPL above 150
app.post('/slack/commands', async (req, res) => {
  const { text, user_id, channel_id } = req.body;
  const [symbol, condition, value] = text.split(' ');

  // Create the alert
  const alert = await stockAlert.alerts.create({
    symbol: symbol.toUpperCase(),
    condition: `price_${condition}`,
    threshold: parseFloat(value)
  });

  // Store metadata in your database for webhook handling
  await saveAlertMetadata(alert.id, { channel_id, user_id });

  res.json({
    response_type: 'in_channel',
    text: `✅ Watching ${symbol.toUpperCase()} to go ${condition} $${value}`
  });
});

// Handle the alert
app.post('/slack-webhook', async (req, res) => {
  const { symbol, price, condition, metadata } = req.body;

  await slack.chat.postMessage({
    channel: metadata.channel_id,
    text: `🚨 Alert: ${symbol} is now at $${price}!`,
    blocks: [{
      type: 'section',
      text: {
        type: 'mrkdwn',
        text: `*${symbol}* hit your target price!\nCurrent: *$${price}*\nAlert by: <@${metadata.user_id}>`
      }
    }]
  });

  res.json({ received: true });
});

Email Digest for Your Users

Building a fintech app? Here's how to use daily reminders to keep users informed:

import { StockAlertClient } from '@stockalert/sdk';

const client = new StockAlertClient({ apiKey: process.env.STOCKALERT_API_KEY });

// Set up daily reminders for user's watchlist
async function setupDailyDigest(userEmail, watchlist) {
  for (const symbol of watchlist) {
    await client.alerts.create({
      symbol: symbol,
      condition: 'daily_reminder'
      // Sends every market day at open with current price
    });
  }
}

// Example: Set up for a user watching tech stocks
await setupDailyDigest('user@example.com', ['AAPL', 'GOOGL', 'MSFT']);

What the user receives every market day:

Subject: Daily Reminder for AAPL: +1.24%

Stock Alert: Daily Reminder for AAPL

Daily Reminder: Apple Inc.
Your daily market open summary for Apple Inc. (AAPL). Current price is $175.23.

Alert Details
Here is your daily update for Apple Inc. (AAPL), as of U.S. market open:

┌─────────────────────────┬──────────────┐
│ Current Price           │ $175.23      │
│ Previous Day's Close    │ $173.08      │
│ Change                  │ +1.24%       │
│ 52-Week High           │ $199.62      │
│ 52-Week Low            │ $164.08      │
│ Volume                  │ 52,341,200   │
└─────────────────────────┴──────────────┘

---
Sent by StockAlert.pro

Each stock gets its own email with:

Current price at market open
Previous day's closing price
Percentage change (color-coded: green/red)
52-week high and low
Trading volume
Proper currency formatting based on user location

Pro tip: For a consolidated digest, use webhooks to collect all alerts and send one combined email:

// Collect daily alerts via webhook
const dailyAlerts = new Map();

app.post('/webhook', async (req, res) => {
  const { event, data } = req.body;

  if (event === 'alert.triggered' && data.condition === 'daily_reminder') {
    // Group by user (you'd need to track this in your DB)
    const userId = await getUserIdByAlertId(data.alert_id);

    if (!dailyAlerts.has(userId)) {
      dailyAlerts.set(userId, []);
    }

    dailyAlerts.get(userId).push({
      symbol: data.symbol,
      price: data.current_value,
      timestamp: data.triggered_at
    });

    // Send digest after collecting all morning alerts
    setTimeout(() => sendConsolidatedDigest(userId), 30000);
  }

  res.json({ received: true });
});

Advanced: Technical Indicators

Monitor RSI, Moving Averages, and more:

// Get notified when a stock becomes oversold
await client.alerts.create({
  symbol: 'TSLA',
  condition: 'rsi_limit',
  threshold: 30,  // RSI below 30 = oversold
  parameters: {
    direction: 'below'  // 'below' or 'above'
  }
});

// Golden Cross alert (50-day MA crosses above 200-day MA)
await client.alerts.create({
  symbol: 'SPY',
  condition: 'ma_crossover_golden'
});

// Price touches moving average
await client.alerts.create({
  symbol: 'AAPL',
  condition: 'ma_touch_above',
  parameters: {
    period: 50  // 50-day or 200-day moving average
  }
});

Error Handling & Best Practices

class StockMonitor {
  constructor(apiKey) {
    this.client = new StockAlertClient({ apiKey });
    this.alerts = new Map();
  }

  async createAlert(config) {
    try {
      const alert = await this.client.alerts.create(config);
      this.alerts.set(alert.id, alert);
      console.log(`✅ Alert created: ${alert.id}`);
      return alert;
    } catch (error) {
      if (error.code === 'RATE_LIMIT') {
        console.error('Rate limit hit, retrying in 60s...');
        await sleep(60000);
        return this.createAlert(config);
      }

      if (error.code === 'INVALID_SYMBOL') {
        console.error(`Invalid symbol: ${config.symbol}`);
        return null;
      }

      throw error;
    }
  }

  async cleanup() {
    // Delete all alerts on shutdown
    for (const [id, alert] of this.alerts) {
      try {
        await this.client.alerts.delete(id);
      } catch (error) {
        console.error(`Failed to delete alert ${id}:`, error);
      }
    }
  }
}

// Graceful shutdown
process.on('SIGTERM', async () => {
  await monitor.cleanup();
  process.exit(0);
});

Testing Your Integration

// Mock webhook endpoint for testing
if (process.env.NODE_ENV === 'development') {
  app.post('/test-webhook', (req, res) => {
    console.log('Webhook received:', JSON.stringify(req.body, null, 2));
    res.json({ received: true });
  });

  // Create a test alert
  await client.alerts.create({
    symbol: 'AAPL',
    condition: 'price_above',
    threshold: 1 // Will trigger immediately
  });

  // For webhook testing, first create a webhook endpoint:
  // const webhook = await client.webhooks.create({
  //   url: 'http://localhost:3000/test-webhook',
  //   events: ['alert.triggered']
  // });
}

Pricing

Free Plan includes:

Monitor up to 50 stocks parallel
Unlimited email alerts
All 21 alert types
1 API key per user
100 API requests/hour

Premium Plan ($14.99/month or $149.99/year):

Unlimited stocks
50 SMS/WhatsApp messages per month
10,000 API requests/hour
Unlimited API keys
Unlimited alerts via API
Priority support

Perfect for testing with the free plan, then scale up when you need more power!

What Will You Build?

I've seen developers use this API to build:

Portfolio tracking apps
Discord/Slack bots
Personal dashboards
Trading journals
News aggregators that react to price movements
Chrome extensions for price monitoring

What are you planning to build? Drop a comment below!

Resources

Get your free API key at stockalert.pro - No credit card required

DEV Community: Alexander Schneider

Configuring Stripe for a European SaaS Startup: A Field Guide

1. Treat the webhook as your source of truth

Verify every signature

Subscribe to the events your code actually handles

Make handlers idempotent

Always return 2xx fast

2. Asynchronous payment methods change the rules

Keep your post-checkout page pending-neutral

3. Resolve plans from data, never from display strings

Do not lean on client_reference_id alone

4. Pricing across EUR and USD without confusing customers

5. Stripe Tax is not optional for EU sellers

Turn on automatic tax and set it per price

Register where you owe, then keep filing in view

Pick tax codes and tax behavior, then be consistent

6. Configure the Customer Portal so it cannot strand a customer

One portal configuration per product line

Decide downgrade timing on purpose

Proration, retention and redirects

7. Dunning: plan for payments that fail later

8. Limit subscription sprawl

9. Price and product hygiene

10. Security and keys

11. Coupons and promotion codes

12. Branding, legal and invoices

13. Test the integration, not just the code

A pre-launch checklist

How We Built a CTO-Grade Grafana Dashboard With Codex

Start With Decisions, Not Charts

Separate Product Health From Observability Coverage

Manage Grafana Assets Like Code

Grafana's MCP Is Actually Useful

Use Grafana Alloy as the Collection Layer

Metrics For SLIs, Logs And Traces For Investigation

Add Domain Metrics, Not Just Infrastructure Metrics

Be Ruthless About Metric Semantics

Test The Dashboard

Where Codex Helped Most

The Dashboard Architecture We Recommend

1. CTO Overview

2. Production Infrastructure

3. Database Performance

4. Tracing

5. Synthetic Monitoring

Security And Cardinality Rules

Practical Tips

Write The Dashboard Goal First

Use Boring Names

Prefer Fewer Panels

Add Links

Test The Intent

Keep Manual Edits Temporary

What "Perfect" Means

How We Built a CTO-Grade Grafana Dashboard With Codex

Start With Decisions, Not Charts

Separate Product Health From Observability Coverage

Manage Grafana Assets Like Code

Grafana's MCP Is Actually Useful

Use Grafana Alloy as the Collection Layer

Metrics For SLIs, Logs And Traces For Investigation

Add Domain Metrics, Not Just Infrastructure Metrics

Be Ruthless About Metric Semantics

Test The Dashboard

Where Codex Helped Most

The Dashboard Architecture We Recommend

1. CTO Overview

2. Production Infrastructure

3. Database Performance

4. Tracing

5. Synthetic Monitoring

Security And Cardinality Rules

Practical Tips

Write The Dashboard Goal First

Use Boring Names

Prefer Fewer Panels

Add Links

Test The Intent

Keep Manual Edits Temporary

What "Perfect" Means

Do not lean on `client_reference_id` alone