Skip to content

Self Hosting is Social: chapters

A proven solution can be shared as a pattern, so someone else can reproduce it.

The service stays on hardware you own. A card is the pattern of how you published it: the programs, the images, the ports, the auth mode on each hostname, and which apps share a serving device.

It is a useful way to hand that pattern to someone else, and a natural fit for Edgible, because an app is already a port, an auth mode, and a serving device. The hostname is created when you publish, so the card leaves out your device name, your hostnames, and your organization id. The next person maps each place to a serving device they have, and Edgible publishes the apps. The auth mode stays None, org, or api-key, separate from the program.

A Compose file says how each program runs. A card adds which hostname is open, which one asks for an org login, and which apps have to share a serving device. That pattern is worth sharing when several apps have to coexist and work together to solve one problem.

What you stop doing is rebuilding a known setup from memory. Website on Edgible and n8n on Edgible are each several apps working together, so this series reproduces each one from a card. The website is four apps in two places. n8n is two hostnames on one process, the editor on org and the hooks on None. One app on one port is a single edgible app create existing, which is the whole job.

Hover a step.

You build several Edgible apps, write them as a card, add files such as tailor.sh, and publish the card. Someone else finds that card, tailors it for their machine, turns it into a stack file, and deploys the stack. You build several Edgible apps, write them as a card, add files such as tailor.sh, and publish the card. Someone else finds that card, tailors it for their machine, turns it into a stack file, and deploys the stack. YOU SHARE Several apps, already published on Edgible. Each one has a port and an auth mode: None, org, or api-key. Apps that share a serving device share a place. 1 Build the apps several Edgible apps One YAML file. It names the programs, the images, the ports, the auth modes, and which apps share a place. It leaves out your device name, your hostnames, your organization id, and any password. 2 Write the card ports, auth, place Optional files beside the card: a Compose file, a sample page, and tailor.sh. The changes list says what to edit. The script applies that list and stops if an edit did not land. 3 Add the files such as tailor.sh A maintainer merges a pull request into the cards repo. That merge is the publish. The pull request checks the card against the schema, and the directory name must match the card name. The maintainer decides whether the card belongs. 4 Publish the card in the cards repo SOMEONE ELSE REUSES Open the cards repo and read the card. The picture lists the apps, the ports, the auth modes, and the places. It names no device and no organization. 5 Find the card in the cards repo Follow the card README. It fetches the Compose files and runs tailor.sh. You supply what is yours, such as an org label. The script does not store a device name, a hostname, or a password. 6 Tailor it for your machine card-to-stack.py reads the card and writes a stack file. It fills in your device name and your organization id. Auth mode org is written edgible-login. 7 Make the stack card-to-stack.py edgible stack deploy publishes the ports in that stack file. The processes are already listening. Deploy does not start the containers. 8 Deploy edgible stack deploy You build several Edgible apps, write them as a card, add files such as tailor.sh, and publish the card. Someone else finds that card, tailors it for their machine, turns it into a stack file, and deploys the stack. You build several Edgible apps, write them as a card, add files such as tailor.sh, and publish the card. Someone else finds that card, tailors it for their machine, turns it into a stack file, and deploys the stack. YOU SHARE Several apps, already published on Edgible. Each one has a port and an auth mode: None, org, or api-key. Apps that share a serving device share a place. 1 Build the apps several Edgible apps One YAML file. It names the programs, the images, the ports, the auth modes, and which apps share a place. It leaves out your device name, your hostnames, your organization id, and any password. 2 Write the card ports, auth, place Optional files beside the card: a Compose file, a sample page, and tailor.sh. The changes list says what to edit. The script applies that list and stops if an edit did not land. 3 Add the files such as tailor.sh A maintainer merges a pull request into the cards repo. That merge is the publish. The pull request checks the card against the schema, and the directory name must match the card name. The maintainer decides whether the card belongs. 4 Publish the card in the cards repo SOMEONE ELSE REUSES Open the cards repo and read the card. The picture lists the apps, the ports, the auth modes, and the places. It names no device and no organization. 5 Find the card in the cards repo Follow the card README. It fetches the Compose files and runs tailor.sh. You supply what is yours, such as an org label. The script does not store a device name, a hostname, or a password. 6 Tailor it for your machine card-to-stack.py reads the card and writes a stack file. It fills in your device name and your organization id. Auth mode org is written edgible-login. 7 Make the stack card-to-stack.py edgible stack deploy publishes the ports in that stack file. The processes are already listening. Deploy does not start the containers. 8 Deploy edgible stack deploy

The card

The cards live in Edgible/cards. card.schema.json is the source of truth for the file. card-to-stack.py writes the stack file, filling in your device name and your organization id. When a card includes tailor.sh, that card's README is how you run it. 1. The website card and 2. The n8n card use the files from that repo.

Each chapter is one job and one smoke test. Do them in order.

Chapters share a shape: a one-line hook under the title, then N.0 Why (what is missing without this chapter, and which machine you run it on), then N.1 The job (what you'll do, how you'll know, what you need, what this is not). Steps after that, a Verify checklist that mirrors Done when, and Next at the end.

Need first: Start here, so a serving agent is installed. The website example also needs Tear down the website stack. The n8n example also needs Tear down n8n.

# Chapter Smoke test
1 1. The website card edgible app list shows site, analytics, umami and status again
2 2. The n8n card edgible app list shows n8n (org) and n8n-hooks (None)
Last updated