How Should a Self-Hosted Software Developer in Spain Combine GitHub, Docker Images, Docs, and Demos?

A self-hosted software developer should give each installable product one portfolio card, state its maintenance and deployment status, and link the destination that best helps the intended visitor evaluate or install it.

A repository may explain the code, a container registry provides an artifact, documentation explains installation, and a demo shows the interface. Those are surfaces of one product, not four unrelated projects, so the portfolio must choose a clear front door.

Which self-hosted projects belong in the portfolio?

Include maintained applications, useful completed tools, substantial public contributions, and honest archived products that still have valid documentation or releases.

State whether you built the whole application, maintain the deployment path, or contributed a specific component. A fork with configuration changes is not an original product unless your work created a distinct maintained outcome.

Use Shipped or Built for usable releases, Building or Working on for active development, and Archived when images, demos, or support have been retired. Do not present an unmaintained image as production-ready.

Maintained app: canonical docs or product page.
Technical library: repository or package documentation.
Runnable preview: demo with no privileged access.
Retired app: archived entry without dead install promises.

What is the fast way to structure self-hosted work with IndieShow?

The fast way is to create one IndieShow card per product, group it by current state, and use one destination as the canonical next step.

Use the tag for a concise category or stack and the description for the problem, your role, and the supported deployment route. The optional metric is not a place for estimates of pulls or users.

Order entries for the visitor: buyers may need the product or docs first, while engineering reviewers may need the repository. The same personal URL can stay stable when a registry or demo changes.

Build your IndieShow pageClaim your handle, organise the projects in the editor, then review the $15 one-year and $30 lifetime publishing options in the dashboard.

Should GitHub, Docker Hub, documentation, and the live demo be separate cards?

No; keep them in one project unless one component has become an independent maintained product with its own users and purpose.

Choose documentation as the destination when it routes people to source, releases, and installation safely. Choose GitHub when code review is the main intent, or a demo when product experience is the strongest proof.

A container registry alone often lacks the context a first-time reviewer needs. Never link a private registry, management console, or demo account containing real data.

How do you present security and maintenance status honestly?

State the supported status and prerequisites, remove exposed administrative surfaces, and archive releases you no longer maintain instead of implying ongoing support.

Do not publish secrets in sample configuration or create a public admin credential for portfolio visitors. Link the maintained security and setup guidance when it exists.

The related IndieShow guides cover open-source package maintenance and API evidence, two useful models for separating code from its documentation and runtime.

Why use IndieShow for self-hosted products?

IndieShow gives each self-hosted product a readable status and explanation while GitHub, documentation, registries, and demos remain the technical sources of truth.

Replace destinations when hosting changes, reorder maintained work above archived software, and keep descriptions aligned with the latest supported release.

The result is one IndieShow page that helps a visitor choose the correct technical surface without mistaking every artifact for a separate project.