LNFly
LNFly is useful when you want to see a Lightning app idea become a working prototype quickly. It is not a production security review. Treat every generated app, NWC connection and Deno backend as code you must inspect before real money touches it.
What LNFly really is
LNFly is a prototype generator for Lightning-enabled web apps. The name in the repository is Lightning Fly, and the README describes the project as a platform to quickly create apps that can earn through Bitcoin Lightning payments. In the NWC ecosystem list, the short version is even simpler: prototype Lightning apps with a single prompt. That description is accurate, but it needs the missing technical context. LNFly is not a wallet, not a Nostr client, not an app store and not a payment processor. It is a lab where a prompt is turned into a small web application that may include payment, wallet and Nostr building blocks.
The implementation is concrete. The frontend is a React 19 and Vite app that lets a user enter a prompt, browse completed generated apps, fork an app prompt and zap apps. The backend is a Fastify service with Prisma and SQLite. It creates app records, streams generation through an OpenRouter-backed AI model, stores the generated HTML and optional Deno code, and exposes preview, publish, backend-control, proxy and zap endpoints. Generated apps are therefore not just static text from a chatbot. They become database rows with edit keys, preview keys, generated source, optional backends and payment-facing settings.
That makes LNFly useful and risky at the same time. It is useful because Lightning app ideas are often blocked by boilerplate: invoices, wallet connection, payment modal state, NWC methods, callback verification and tiny backend routes. LNFly places that knowledge in the generation context so a builder can test an idea quickly. It is risky because the generated result is still code created by an AI system. If the app can ask a wallet to make or pay invoices, you must review the code before giving it more than a tiny testing budget.
Why it belongs in AI
The correct hub category for LNFly is AI because the primary user action is prompt-driven generation. The Lightning and Nostr pieces are the ingredients the generator knows how to use. You do not open LNFly because you need a normal timeline, a wallet dashboard or a relay tool. You open it because you want an app idea to become a runnable prototype without writing every integration by hand.
The code supports that reading. The backend has an AI agent module that selects a default model, builds a system prompt, streams generated code and then asks the model to title and evaluate the generated result. The system-prompt builder explicitly says the AI should generate a complete single-file HTML application, and, if server-side logic is needed, a single Deno TypeScript backend file. This is not just a directory entry saying AI. The application architecture is built around AI-generated app code.
The payment context is what makes LNFly different from a generic app generator. The prompt knowledge includes Bitcoin Connect, WebLN, NWC, Lightning invoice tools, Nostr note posting, Nostr subscriptions, React, Deno and PPQ.ai backend prompting. In other words, it is an AI app builder with a Lightning and Nostr vocabulary. That is the real product shape.
The June 2026 status check
The current status needs a plain note because the live checks were not clean. On June 13, 2026, direct requests from this environment to `https://lnfly.albylabs.com/` and `https://blotto.lnfly.albylabs.com/` failed during the TLS connection, and `https://lnfly.com/` timed out. That does not prove the service is permanently down for everyone, but it means a reader should verify reachability before depending on the hosted app.
The repository was available and inspectable. GitHub metadata for `getAlby/lnfly` showed a public TypeScript repository created on April 19, 2025, with the default branch `master`, a last pushed timestamp of August 2, 2025 and a small public footprint: six stars, three forks and fourteen open issues when checked. The latest shallow-clone commit was `96bdd2d`, dated August 2, 2025, with the message fixing versions when using esm.sh.
That mix matters. LNFly has real code, but the hosted service should be treated as something to test at the time of use. If you are reading this because you want to build a paid app today, start by opening the hosted site, checking whether generation works, and creating a throwaway test wallet connection. Do not assume that a historical NWC map entry or an old example subdomain means the public service is healthy.
The generated app shape
LNFly's generated output is intentionally small. The system prompt asks for a complete single-file HTML application. It tells the model to include the HTML structure, CSS and JavaScript inside one file, to use CDN imports only when external JavaScript is needed, and to avoid fake demo invoices or unfinished TODO code. If the requested app needs state, APIs or server-side work, the model may also produce a single Deno TypeScript backend file.
This shape is practical for prototyping. A single HTML file can be previewed quickly, stored in the database and served through the app view route. If a backend exists, LNFly stores it separately as Deno code, starts it as a child process and proxies frontend requests through `/api/apps/
It is also a limitation. A one-file frontend and one-file Deno backend are not a full software product architecture. There is no migration plan for a serious multi-service app, no human-authored test suite by default and no guarantee that the generated code handles every edge case. LNFly is best read as a fast sketchpad that can prove whether an idea is worth building properly.
Bitcoin Connect is the user-facing payment layer
Bitcoin Connect is one of the most important knowledge segments in LNFly because it gives generated apps a user-facing wallet connection surface. The frontend package depends on `@getalby/bitcoin-connect-react`, and the prompt knowledge teaches two patterns: launching a payment modal for an invoice, and using WebLN-style wallet connection flows. For a prototype, that means the user does not need to install a special extension just to test whether a payment flow feels possible.
The payment-modal segment is clear about its role. It is for paying an invoice and doing something once the invoice was paid. It is not meant to be the only segment if the app also needs invoice generation. In generated app logic, that distinction matters. An app needs some way to create or receive an invoice, and then a wallet-facing way for the user to pay it.
A reader should test the modal with tiny amounts. Good generated payment code should show the invoice, open the wallet flow, poll or listen for confirmation, set the paid state only when a preimage or trusted verification path exists, and handle cancellation. Bad generated payment code may mark a feature as paid too early or keep polling forever. LNFly can give the model the right ingredients, but you still need to inspect the meal before serving it to users.
NWC is the deeper wallet power
NWC is where LNFly becomes more than a paywall generator. The NWC knowledge segment teaches generated code how to create an NWC client using `@getalby/sdk`, then call wallet methods such as `payInvoice`, `makeInvoice`, `lookupInvoice`, `getBalance` and `listTransactions`. It also reminds the generator that NWC amounts use millisatoshis, where one satoshi equals one thousand millisatoshis.
This is powerful because NWC lets a generated app ask a wallet to do useful work without the app itself becoming a wallet custodian. A lottery app can create invoices for tickets and look them up. A vending app can charge for an unlock. A dashboard can show recent transactions if the wallet permission allows it. A small automation can pay an invoice from a limited connection. These are exactly the kinds of flows that make Lightning apps feel native to the web.
It is also the highest-risk part of LNFly. A Nostr Wallet Connect string is a capability. If a generated frontend exposes it, logs it, stores it carelessly or asks for too much permission, the user can lose funds within the budget and permissions of that connection. When testing LNFly output, create a dedicated NWC app connection, keep the budget tiny, limit methods, avoid `pay_invoice` unless the prototype truly needs it and revoke the connection after the test.
Lightning Tools cover invoice edges
LNFly also teaches the model about Alby's Lightning Tools. The request-invoice segment uses a Lightning Address to fetch metadata, request an invoice for a satoshi amount and later verify payment. The parse-invoice segment uses the Invoice helper to read useful BOLT11 data such as amount and description. These are smaller than NWC, but they are exactly the details that many payment prototypes get wrong.
Lightning Address invoice requests are useful when the app is collecting money for a recipient rather than operating directly as that recipient's wallet. A generated app can ask a Lightning Address for an invoice, then use Bitcoin Connect to let the user pay it, then verify the payment if a verify URL is available. This pattern is well suited for small paid features and proof-of-concept paywalls.
The boundary is that Lightning Tools are not a complete anti-fraud layer by themselves. Invoice verification depends on the invoice source and its verify mechanism. Parsing an invoice tells you what the invoice claims, not whether a service should trust the buyer. If the generated app unlocks something valuable, you need a backend-side verification story, replay protection and clear handling for expired or reused invoices.
Nostr support is specific, not universal
The README lists supported Nostr functionality as signing and posting notes. The codebase also includes a Nostr subscription knowledge file, but the README still marks broader Nostr querying knowledge and Nostr zaps knowledge as not yet complete. That is an important distinction. LNFly can help generate a prototype that posts a Nostr note, but it should not be described as a fully Nostr-aware app generator.
The post-note segment uses `nostr-tools` with relays such as `wss://nos.lol`, `wss://relay.damus.io` and `wss://purplerelay.com`. It shows both backend-style signing from an `NSEC` and frontend-style signing through `window.nostr.signEvent`. That gives the generator a path for simple announcements, game updates or receipts. The Blotto prompt uses exactly this idea: post notes when a game starts, ends, receives tickets, receives donations or pays a winner.
The user-risk line is private-key handling. An `NSEC` in a generated backend environment can publish notes, but it is still a secret key. If you let a prototype generate or use Nostr keys, decide whether it should be a throwaway bot key, a signer-mediated user key or a service key with limited reputation. Do not paste a valuable personal nsec into a generated app just because the prototype asks for one.
Deno backend sandboxing
LNFly's Deno backend design is one of the more interesting parts of the project. If the generated app includes backend code, the server writes that Deno TypeScript code to a temporary file, assigns a port starting around 9000, prepares an app-specific storage file and spawns a Deno process. The command allows network access, allows a small set of environment variables and limits file read/write access to the app's storage path.
That is a sensible prototype sandbox. The generated code can fetch remote APIs, talk to NWC, read a Lightning Address, store simple state and respond to proxied frontend requests, but it is not supposed to read the whole server filesystem. The process is also started on demand and tracked with a backend state in the database. LNFly resets running, starting and stopping backends to stopped on server startup, which avoids assuming stale child processes survived a restart.
The sandbox is not a production security proof. The Deno process has network access, receives secrets through environment variables and runs code generated by an AI model. The manager uses basic port allocation and simple process lifecycle tracking. That can be fine for a lab, but a public paid app should go through normal review: code audit, dependency pinning, rate limits, logging review, resource limits, wallet permission limits and abuse testing.
The ten-minute backend clock
LNFly's README says generated app backends stop automatically after ten minutes, and the Deno manager confirms that design. It stores last activity time for running apps, resets the timer when the app is viewed or proxied, and stops the Deno process when the inactivity window is exceeded. That is a useful guardrail for a public prototype host because generated backends should not run forever just because someone clicked a button once.
The user experience tradeoff is startup delay. If a generated app has been idle and then receives a proxied request, LNFly may need to start the backend before the request can succeed. The proxy route can return a busy or starting response when the backend is not ready. A generated frontend should handle that state gracefully instead of assuming every API call is immediate.
For builders, the ten-minute clock is another reminder that LNFly is a prototype environment. Apps that need durable always-on services, long-running jobs, scheduled tasks or reliable public APIs will outgrow this shape. Use LNFly to explore the payment and interaction design, then move serious projects into infrastructure you control and monitor.
App keys and publishing
When LNFly creates an app, the backend immediately returns an app ID, an edit key and a preview key. The frontend stores those keys in local storage under app-specific names. The edit key unlocks sensitive operations such as updating settings, changing the title, publishing, setting the NWC URL, setting an nsec, regenerating the app, clearing storage and starting or stopping the backend. The preview key lets an unpublished generated app be viewed.
This is convenient, but it is not the same as a full user account. If your browser storage is cleared, moved or compromised, your ability to manage the app changes. If someone obtains the edit key, they can alter important fields. If a published app contains a risky backend or an overpowered wallet connection, the edit key becomes part of the operational security story.
The publish flow also supports subdomains. The server checks that a subdomain contains only lowercase letters and digits, then can route subdomain requests to the app's view endpoint. That makes generated apps feel more like standalone creations. It also means readers should verify which app they are on, whether a preview key is involved and whether the app ID or subdomain maps to the expected prompt and owner.
Explore, fork and zap generated apps
LNFly is not only a private generator. The frontend has an Explore Apps component that loads completed and published apps, ordered by their zap amount. A visitor can view an app, fork its prompt back into the generator or zap it up or down. That gives the project a small gallery and feedback loop around generated Lightning apps.
The zap route uses a service NWC connection from the environment. When a user zaps an app, the backend creates an invoice with `makeInvoice`, stores the zap as unpaid and returns the invoice and zap ID. The frontend opens Bitcoin Connect, then polls the backend for zap status. The backend checks the invoice with `lookupInvoice` and marks the zap paid only when a preimage is present, then increments or decrements the app's zap amount depending on whether the user chose an upzap or downzap.
That design is playful, but it is also a real payment flow. It depends on the operator's `SERVICE_NWC_URL`, invoice lookup behavior and database updates. If the hosted service is running, a reader should treat zaps as payments to the service's configured wallet, not as NIP-57 zaps to a Nostr profile unless the app explicitly documents that mapping. The word zap can mean different things in different Nostr and Lightning contexts.
Blotto shows the intended ambition
The best example of LNFly's ambition is Blotto. The NWC ecosystem account posted that LNFly made prototyping Lightning apps easier and pointed to Blotto as an app created by LNFly. The repository also includes an advanced prompt for Blotto, a Lightning lottery app where people buy tickets, each payment increases the countdown, the backend verifies invoices and Nostr notes announce important game events.
The Blotto prompt is long because real payment apps are not simple. It specifies game storage, ticket IDs, hidden IDs, paid invoice verification, payment preimages, donation logic, prize pool math, previous-game history, claiming rules, payout invoices, NWC payout behavior, countdown behavior, Nostr announcements and AI-assisted event copy. That is exactly the kind of prompt that reveals what LNFly is trying to do: not just draw an interface, but generate a working paid app with state and wallet interactions.
It also reveals why review matters. A lottery app has money, randomness, receipts, claims, deadlines, payout invoices and public announcements. Generated code may capture the happy path while missing legal, security or edge-case constraints. Blotto is a great demo of possibility, but any real-money version would need a human audit, clear rules, jurisdictional review and careful wallet limits.
Model selection and prompt quality
LNFly's backend uses OpenRouter through the Vercel AI SDK stack and sets a default model named `qwen/qwen3-coder:free` in the inspected code. The generation process first asks the model to choose relevant knowledge segments from the available list, then builds the full system prompt and streams code. After generation, it asks the model to produce a title and evaluate the original prompt's clarity.
That flow is useful because the system prompt should not always include every possible capability. A simple frontend paywall does not need Nostr subscriptions, PPQ.ai backend prompting and NWC payouts. A stateful game does need backend storage, invoice creation and payment verification. LNFly's segment-selection step is a practical attempt to keep the generation context relevant.
The README is honest about output quality: result quality varies widely, and if an app does not work, the user should try regenerating the prompt. That warning belongs near the top of any practical guide to LNFly. AI-generated app code can look finished while hiding broken imports, race conditions, weak validation or unsafe secret handling. Regeneration can help, but it is not a substitute for reading the generated code.
What to inspect before connecting money
Before you connect a wallet to an LNFly-generated app, inspect what the app is trying to do. Look for the methods it requests, where the NWC connection string is stored, whether the app uses a frontend provider or backend environment variable, whether it can pay invoices automatically and how it verifies invoice settlement. If you see `payInvoice`, treat the app as capable of spending from the connected wallet within its budget and permissions.
Then inspect the generated backend, if one exists. Look at every endpoint, every environment variable, every storage read and write, and every outgoing fetch. Confirm that it validates amounts in sats versus millisats, rejects replayed invoices, handles expired invoices and avoids exposing NWC strings, nsecs, preimages or edit keys in public responses. If a generated app publishes Nostr notes, check which key signs them and which relays receive them.
Finally, test with very small values. Use a fresh NWC app connection, set a low spending cap, create one invoice, pay one invoice and then revoke the connection. Check your wallet history and the app state after each step. LNFly can shorten the distance from idea to prototype, but it should not shorten your due diligence.
What LNFly is not
LNFly is not Alby Hub. It can use NWC and Alby tooling, but it does not run your Lightning node or hold your whole wallet experience. It is not Bitcoin Connect itself, although it can generate apps that use Bitcoin Connect. It is not the Alby MCP Server, which exposes wallet actions as MCP tools for AI agents. LNFly's center of gravity is generated app code.
It is also not a Nostr DVM marketplace. The project is adjacent to AI and Nostr, but the inspected README does not claim NIP-90 DVM job publishing. Its Nostr functionality is narrower: signing and posting notes, with some subscription knowledge present in code and broader Nostr querying still marked as a TODO. Do not assume every AI plus Nostr project is a DVM.
Most importantly, LNFly is not a production guarantee. A generated app that works once in a browser is not automatically safe, maintainable or legally appropriate. Use LNFly to learn flows, test ideas and discover what a payment interaction might feel like. When the idea becomes serious, move it into a normal development process.
How a builder should use it
A good LNFly workflow starts with a narrow prompt. Ask for one payment behavior, one state model and one public action. For example, a simple invoice-gated message board is a better first test than a marketplace, escrow system and moderation dashboard in one prompt. The smaller the first prototype, the easier it is to see whether the payment and wallet code are sane.
After generation, read the app before showing it to anyone. Check the HTML, script imports, backend code, storage model, wallet calls and user messages. If it uses NWC, rewrite the prompt or generated code until the permission story is obvious to the user. If it posts to Nostr, make sure the public notes are not leaking private data. If it asks for a Lightning Address, confirm who receives the funds.
Then fork or regenerate deliberately. LNFly supports prompt regeneration for unpublished apps, but published apps cannot be regenerated through that route. That is a useful guardrail because changing a live app's behavior after users have interacted with it can break trust. Treat each prompt iteration as a new draft, not as a patch to a production app.
How a user should test an LNFly app
If someone sends you an LNFly app, start by asking what it wants from your wallet. Does it only ask you to pay a displayed invoice? Does it ask to connect a wallet through Bitcoin Connect? Does it ask for an NWC connection that can create or pay invoices? Does it ask for a Lightning Address or a Nostr private key? Each of those is a different trust boundary.
Use a wallet setup that assumes the app might be wrong. Create a small, dedicated NWC connection with a spending limit. Never paste your main nsec into a generated page. Do not trust an app to pay out winnings, refunds or rewards unless the code and operator are clear. If a page says it verified payment, compare that with your wallet history and invoice preimage state.
Also check the domain and app ID. LNFly can serve generated apps through app IDs and subdomains. A polished generated page can look independent even when it is still hosted inside the LNFly environment. That is fine for testing, but you should know who operates the host, what data it stores and whether the backend can be restarted or changed by someone with the edit key.
The practical close
LNFly is one of the more interesting AI-and-Lightning experiments because it does not stop at a chat answer. It tries to turn a prompt into a runnable payment app, with the right concepts close at hand: Bitcoin Connect for wallet UX, Lightning Tools for invoice work, NWC for app-to-wallet power, Deno for small backends and Nostr tools for announcements.
Its best use is learning and fast exploration. If you are a builder, LNFly can help you discover the awkward parts of a payment app before you invest a week in scaffolding. If you are a user, it can show what small Lightning apps might feel like when they are easy to create. In both cases, the wallet boundary deserves respect.
The rule is simple: prototype quickly, fund slowly. Verify the live service, inspect the generated code, use tiny wallet permissions, keep secrets out of throwaway apps and graduate serious ideas into reviewed code. LNFly is a launchpad for experiments, not a replacement for responsibility.
Sources worth opening
Open the LNFly repository first, then read the README, backend routes, Deno manager, system-prompt knowledge files and Prisma schema. The useful external context is NWC/NIP-47, Bitcoin Connect, Alby SDK, Lightning Tools and the NWC ecosystem references that point to LNFly and Blotto. The key question is not whether a one-prompt prototype can be impressive. It is what permissions, secrets, generated backend code and payment assumptions the prototype introduces.
- LNFly GitHub repository
- LNFly README
- LNFly raw README
- LNFly backend package.json
- LNFly frontend package.json
- LNFly backend environment example
- LNFly Fastify server
- LNFly app routes
- LNFly Deno manager
- LNFly AI agent
- LNFly system prompt builder
- LNFly NWC knowledge segment
- LNFly Bitcoin Connect NWC segment
- LNFly Bitcoin Connect payment modal segment
- LNFly Bitcoin Connect WebLN segment
- LNFly Lightning Address invoice segment
- LNFly Lightning invoice parse segment
- LNFly Nostr note posting segment
- LNFly Nostr subscribe segment
- LNFly Deno knowledge segment
- LNFly AI backend knowledge segment
- LNFly React knowledge segment
- LNFly Prisma schema
- LNFly frontend App component
- LNFly Explore Apps component
- LNFly Zap modal component
- LNFly Blotto advanced prompt
- getAlby awesome-nwc list
- getAlby awesome-ai-bitcoin list
- NWC official website
- NWC documentation
- NWC specification page
- NIP-47 Nostr Wallet Connect
- NWC one-click wallet connections
- Alby Bitcoin Connect repository
- Alby JS SDK repository
- Alby Lightning Tools repository
- Alby App Connections via NWC guide
- Alby blog
- LNFly hosted app
- Blotto LNFly example
- NWC Nostr profile note mentioning LNFly and Blotto
