A digital product is really two things: a page that convinces someone to buy, and a file that shows up afterwards. Most platforms only support one way of supplying that file — you upload it, and if you ever change it, you upload it again. Sellify gives you three routes to the same place: a manual upload, a link to a GitHub release, or the REST API. They're not just different buttons; they suit genuinely different products. This is a tour of all three, plus the fourth case where the file doesn't exist yet when the buyer pays.
Option 1: upload the files yourself
The default path is the obvious one. In the product editor you drop in your PDF, zip, video, audio, or whatever else you're selling, and it's stored privately — not on a public URL somebody can guess or share. When a buyer downloads, Sellify hands their browser a short-lived signed link that expires shortly after it's issued, so a link copied out of someone's history is worth nothing an hour later. Your file is never sitting on the open internet, which is the part most creators get wrong when they rig up their own delivery with a cloud drive.
You can attach several files to one product, which is how most real products actually ship: the main deliverable, a quick-start guide, source files, a bonus. If your product uses pricing tiers, you can also decide which files belong to which tier, so the $29 buyer gets the templates and the $99 buyer gets the templates plus the source and the video walkthrough — one product page, one checkout, two different download sets. Manual upload is the right default for anything that's finished, self-contained, and doesn't change often: an ebook, a preset pack, a course download, a template bundle.
Option 2: sell straight from a GitHub release
If what you sell is software, the upload model starts fighting you. You already have a release pipeline; a build already gets tagged, packaged, and attached to a GitHub release. Re-uploading that same artifact to a store every time you ship a patch is duplicated work, and the moment you forget, your buyers are downloading a stale build. So Sellify lets a product point at a GitHub release asset instead of a file you uploaded.
You connect your GitHub account once from Profile → Connections. After that, the product editor shows a GitHub release card: pick a repository from the ones your account can reach (your own, ones you collaborate on, and your organizations'), pick a published release, then pick which asset from that release is the thing you're selling — by file name, since a release usually carries several builds. Private repositories work exactly the same way. Sellify authenticates with your connection, so buyers get the file without ever seeing, or needing access to, the repo behind it.
How the GitHub link behaves at download time
The important detail is when the link is resolved. Sellify doesn't copy your asset at setup time — it resolves the release at the moment a buyer downloads, then streams that asset to them. That makes the choice between the two release channels meaningful. Choose "latest" and every buyer, including the ones who bought months ago, always gets your newest published release; shipping an update to your customers is just publishing a release, with nothing to do in your store. Choose a specific tag and the product is pinned to that exact version forever, which is what you want when you're selling v2 as a separate product from v3, or archiving a version you still support.
Two practical notes. If you're tracking "latest", keep the asset's file name stable between releases — the link is by name, so a build that goes out as app-1.4.0.zip and then app-v1.5.0.zip will break the match. And drafts are ignored on purpose: only published releases are eligible, so an unfinished draft can never leak to buyers. The editor card shows which release tag was resolved last and when, and surfaces the error if a resolution ever fails, so a renamed asset or a deleted release shows up in your dashboard rather than in a customer support email.
Option 3: create products and push files over the API
Everything above has a REST equivalent. Create an API key from Profile → API keys (it looks like sp_), then POST /api/v1/products with a title, slug, and price to create the product, POST /api/v1/products/:id/files to upload the deliverable as multipart, and POST /api/v1/products/:id/banner to set the cover image. The same product payload accepts a tiers array if you want several pricing options, and PUT /api/github/products/:id/source links a product to a GitHub release asset without ever opening the dashboard.
This is the route to take when the store isn't where the work happens. If you generate products programmatically, migrate a catalogue from another platform, or want your CI pipeline to publish a new product the same way it publishes a build, the API removes the human from the loop entirely. It's also what makes Sellify usable by AI agents: an agent with an API key can create the product, write the description, upload the file, and publish, end to end. The full walkthrough with request bodies and curl examples lives in documentation/product-api-workflow.md and in the API docs page in your dashboard.
The fourth case: no file at purchase time
All three sources above assume the deliverable exists before anyone buys. Sometimes it doesn't — a custom report, a personalised audit, a made-to-order design. For that, Sellify has deferred products: the buyer fills in an intake form at checkout, pays, and you upload the finished file afterwards, with the payment protected by a delivery deadline. It's a different mechanism with its own rules, and it has its own article on this blog.
So the decision tree is short. Finished and static? Upload it. Software that ships new versions? Point it at your GitHub releases and pick "latest". Managed by a script, a pipeline, or an agent? Use the API. Produced individually per customer after they pay? Make it a deferred product. Nothing stops you from mixing them across your catalogue either — the buyer's experience is identical in every case: they pay, and the download appears in their library.
Where your files come from is a decision worth making once, per product, with the shape of that product in mind — because the wrong choice quietly costs you either manual re-uploads or stale downloads for your customers. Open your dashboard, look at your best-selling product, and ask which of the four it really is. If it's software you're still shipping updates for, connect GitHub from Profile → Connections and switch it over; your next release will reach every past buyer without you touching the store at all.
