The first rule is to optimize net sats, not routed volume or node rank:

net = forwarding fees + liquidity-lease income - rebalance/swap fees - allocated open/close fees

Track that per million sats of your deployed capital per day. A channel that routes 1 BTC but needs 1,500 sats of rebalancing to earn 800 sats is not profitable.

1. Measure the traffic only your node can actually see

For LND, export 30 days of successful forwards with lncli fwdinghistory --start_time=-30d --max_events=50000. Also subscribe to routerrpc.SubscribeHtlcEvents; local INSUFFICIENT_BALANCE / HTLC_EXCEEDS_MAX failures show attempted traffic that reached your node but your outgoing channel could not serve. For CLN, lightning-cli listforwards exposes settled and failed in/out channel pairs.

Build a matrix for each incoming_channel -> outgoing_channel pair:

• settled sats, fees earned, count and payment-size percentiles;
• failed sats/count by reason;
• uptime and disabled time;
• liquidity-management cost attributed to the outgoing channel.

This is much better than opening to the largest node on Amboss. Public gossip exposes topology, capacity and fee policy—not actual balances or payment volume. Centrality is a prior, not proof of demand.

2. Find complementary peers, not merely “popular” peers

A routing node needs an incoming-liquidity source and an outgoing-liquidity sink at the same time. Look for repeated successful or liquidity-failed channel pairs in your own data. Prefer peers that are reachable, stable, have sensible HTLC limits, and add a direction your current node lacks.

For an untested peer, open only a trial channel sized above your observed payment distribution and large enough that the fixed chain fee is not absurd. Run it for 2–4 weeks, then keep/expand it only if net revenue and availability beat your existing channels. Do not spray many tiny channels or buy rank.

The strongest way to create organic flow is to operate a real service—merchant receiving, payouts, wallet/LSP, paid API, etc. It gives the node predictable demand. Routing fees alone rarely repay hardware, on-chain fees, capital and operator time.

3. Use a slow, bounded fee controller

Reprice at most every 2–3 days; use a dead-band so gossip is not churned:

• outbound balance scarce and observed demand high: raise ppm 10–20%;
• outbound plentiful but underused: lower ppm 10–20%;
• scarce but no demonstrated demand: do not raise forever—retire or repurpose the channel;
• cap absolute fees and each step; preserve a manual allow/deny list.

Start any automation in dry-run. charge-lnd can match balance ratios, activity, capacity and on-chain conditions and supports --dry-run. Lightning Terminal Autofees uses historical throughput and balance scarcity, with small changes every three days. Pick one fee controller, not two competing writers.

4. Rebalance only behind a profit gate

Do not blindly restore every channel to 50/50. Before a circular rebalance or swap, require:

expected extra forwarding fees during the payback window > rebalance cost + safety margin

I would initially require at least 2x coverage and a payback under 7–14 days. Never pay 500 ppm to refill liquidity that historically sells for 100 ppm. Use the actual destination channel's recent forwarded volume and fee revenue, not a network-wide guess.

For LND, Loop's SuggestSwaps lets you observe recommendations before enabling Autoloop. If you enable it, set a hard fee budget, one in-flight swap, long sweep confirmation target and failure backoff. Pool is another option: sell outbound liquidity when a buyer pays enough to cover chain and capital costs, or buy inbound only when your own demand justifies it.

5. A practical operating loop

Hourly: alert on chain/graph sync, peer/channel down state, disk, pending HTLCs and failed-forward spikes.
Daily: update the flow matrix and net P&L; do not change policies from one noisy day.
Every 3 days: bounded fee update.
Weekly: approve only positive-EV rebalances; rank channels by net sats per deployed-capital-day.
Monthly: expand proven pairs; close persistently negative channels when chain fees make closure sensible.

Keep the node online behind a UPS, use reliable SSD storage, monitor it, maintain and test seed/channel recovery material, and use least-privilege macaroons for automation. Never expose an admin macaroon to a dashboard or remote fee service. A Raspberry Pi can route; “always online, observable and recoverable” matters more than the logo on the box.

Primary references:

• LND ForwardingHistory: https://lightning.engineering/api-docs/api/lnd/lightning/forwarding-history/
• LND HTLC event stream: https://lightning.engineering/api-docs/api/lnd/router/subscribe-htlc-events/
• CLN listforwards: https://docs.corelightning.org/reference/listforwards
• Autoloop budgets/dry recommendations: https://docs.lightning.engineering/lightning-network-tools/loop/autoloop
• Lightning Terminal Autofees: https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/autofees
• charge-lnd: https://github.com/accumulator/charge-lnd
• Pool: https://docs.lightning.engineering/lightning-network-tools/pool

AI-assisted research, checked against the primary interfaces above. I would still test every policy in dry-run/regtest before granting it fee or payment authority.