Vote for Brianoflondon's Witness KeyChain or HiveSigner
Support Proposal 378 on PeakD

This is a value for value post: see the explanation in the footer.

V4V.app is staying online

TL;DR

I am keeping @v4vapp running.

Voltage is still killing self-serve Lightning hosting, so I still have to move the production Lightning node. That work is going ahead. I am also rationalising the number of servers I run to get monthly costs down. Fees alone still do not cover hosting, so witness votes (and the usual Value for Value support) actually matter for whether this stays viable long term.

There may be downtime this week while I cut over. For a while I will also be without a separate dev system for testing — my home/dev Umbrel is becoming production — so fixes may take longer than usual if something odd shows up after the move.

If you only need one sentence: I am not shutting @v4vapp down; I am moving house under the pipes and trying to make the rent smaller.

The decision

A week or so ago I wrote What is the Future of V4V.app? because Voltage is sunsetting self-serve and my production node lives there. Hard end date still stands: 31 August 2026.

I had two real options: do the migration work, or wind the service down on their timeline.

I am choosing the work.

I want @v4vapp open. I want Hive to have a simple bridge in and out of Lightning. Backend v2 finally made the day-to-day running almost automatic; I am not throwing that away because a host decided hobbyists and small builders are no longer the product.

That does not mean the money problem went away. Hosting was on the order of ~$200/month, fees do not cover close to that, and usage is not heavy. So the plan is not “spend more forever.” The plan is: move the node, slim the server footprint, and ask for the support that actually keeps the lights on.

What I am doing (high level)

You do not need the full ops runbook. Here is the shape of it:

1. Move production Lightning off Voltage onto my Umbrel node

Production today talks to a Voltage LND node. I am pointing the live system at an Umbrel Lightning node instead — one I already run / control — so I am not stuck on Voltage’s self-serve calendar or enterprise sales funnel.

Lightning nodes do not “export and import” like a website. Channels, liquidity, invoices, and payments all have to be treated carefully so nobody’s Keepsats history or mid-flight deposit gets double-counted or lost.

2. Keep the ledger as the source of truth

Your balances and completed history live in the ledger, not in a pile of old Voltage invoices. On cutover I will:

Finish any in-flight Lightning deposits and payments on the old node first (no half-done stage-2 deposits left hanging).
Archive the old live invoice/payment event data (for forensics if needed).
Start clean event streams from the Umbrel node from a known point forward, so we do not re-process ancient Umbrel history as if it were new customer activity.
Record new Lightning activity under a clear umbrel ledger sub-account; Voltage-era external Lightning history stays frozen under voltage. Keepsats customer balances stay continuous.

In plain language: accounting history stays; the live Lightning pipe gets a new home.

3. Re-wire config, deposits, and smoke-test with small real flows

After the switch I need to confirm:

Monitors see the Umbrel node (right identity, right subscription point).
Small inbound settle → Keepsats / Magi paths still work.
Small outbound pay from Keepsats still works.
Opening balances and node balance look sane before anyone leans on the gateway again.

4. Rationalise servers and cut cost

In parallel I am reducing how many machines this stack depends on. Fewer servers, less monthly cash burn, less sysadmin surface. That is part of making “keep it running” a rational choice rather than a slow bleed.

I will share concrete cost numbers once I know what the slimmed setup actually costs month to month. Right now the honest goal is: same useful bridge, less infrastructure tax.

Downtime and rough edges this week

Cutover is not a free lunch.

Expect possible downtime this week while production is pointed at the new node and I verify the pipes. Prefer not to start large transfers until I post that things look good again (I will update this post or a follow-up when status is clear).
I will be without a proper separate dev Lightning environment for a while. The node that was useful for testing is becoming production. That means I am flying with less of a safety net: more care on cutover, but slower iteration if something weird only shows up live.
If something fails mid-flight, comment here or use Telegram — same as always.

If you hold Keepsats: they remain yours in the ledger through this. Still, as always with any bridge, do not park more than you are comfortable moving when the operator is mid-migration.

How you can help keep this going

Blunt version:

Vote for my Hive witness — vote.hive.uno/@brianoflondon (or Keychain / HiveSigner). Witness rewards are one of the few recurring ways this work is funded that is not “hope fees magically cover $200 of hosting.”
Use the service when you need it — a bridge nobody uses is hard to justify. A bridge people use is easier to fight for.
Upvotes / tips / Lightning if the work is useful to you — Value for Value still applies.

I am doing the engineering. Sustainability is a community choice as much as a technical one.

What is not changing (on purpose)

Keepsats balances and completed history stay on the ledger.
Hive / HBD ↔ sats gateway intent stays the same.
Magi / Lightning address paths remain part of the story; the backend still has to talk to some LND after the move.
This is still a gateway, not a replacement for an exchange. Rate limits stay in that spirit.

What is changing is where the Lightning node lives, how carefully we avoid replaying old node history into live accounting, and how many paid boxes I am willing to run to keep the lights on.

Timeline (honest, not polished)

When	What
This week	Drain old node of in-flight work, archive Voltage-era event collections, cut production to Umbrel, smoke-test, possible downtime
After cutover	Watch live traffic, fix anything that only appears without a dev node, continue server rationalisation
Before 31 Aug 2026	Be fully off Voltage self-serve (hard external deadline)

I will edit this post or publish a short “ALL GOOD” style update when production is stable on the new node.

No drama, just the next step

Voltage chose enterprise. That is their business.

I am choosing to keep @v4vapp alive, move the node to infrastructure I control, spend less on servers, and ask you — if this bridge matters to you — to vote the witness and help me carry the cost.

Thank you for patience through the v2 saga, for any support already given on the last post, and for sticking with a one-person Lightning–Hive pipe that was never going to print money.

Comments under this post or Telegram if you have constraints I should know about before or during the cutover.

Value for Value

For the last few months while building @v4vapp I was generously supported by the DHF. Going forward I have a much more modest support which covers direct server costs and a little of my time.

If you appreciate the work I do on and around Hive, you can express this directly: upvoting posts on Hive is great. Also consider a direct donation (there's a Tip button on Hive or a Lightning Address) on all my posts.

Vote for Brianoflondon's Witness KeyChain or HiveSigner

V4V.app is staying online: moving the Lightning node and cutting costs