Small Grant: hostd-guard: Deployment preflight + policy linter for hostd

INTRODUCTION

Project Name:
hostd-guard: Deployment preflight + policy linter for hostd

Name of the organization or individual submitting the proposal: Dapps over Apps
Dapps over Apps track record (GitHub / shipped tooling):

Describe your project.
Host setup has a bunch of “looks fine” failure modes that still hurt you in practice: a port is missing (especially UDP for QUIC), your advertised address is wrong/stale, Docker accidentally exposes the admin API, or pricing/collateral settings don’t line up and the host ends up unusable/risky. The docs make it clear the host address is what renters use to connect and that specific ports must be forwarded.

hostd-guard (MVP) is a repo-local CLI + GitHub Action that runs a preflight before you announce a host and whenever you change config. It’s a safety gate for hostd.yml and (optionally) your Docker Compose file. It checks:

  • Network + announce basics: address format/sanity and required port mappings in your config/deploy (including UDP where required)
    (Important: this MVP checks what your config/deployment says — it does not “prove” your router/NAT is correctly forwarding.)
  • Docker safety: detects when 9980 (admin API) is bound publicly (e.g., 0.0.0.0:9980) instead of localhost
  • Policy sanity: pricing/collateral/max-collateral sanity checks using the docs’ rule-of-thumb relationship, with a configurable tolerance. This is a “catch obvious bad configs early” check — not a profitability calculator.

Outputs are machine-readable (report.json + optional report.sarif) plus a short console summary with exact fixes. Default mode is fully offline and deterministic (CI-friendly).

Small Grant MVP is offline-only. Read-only live checks (calling hostd endpoints / connect-test) are intentionally not in scope for this $10k version — that’s a follow-up if the MVP gets used.

This is not monitoring, not benchmarking, not a hosted service, and not a troubleshootd replacement. It’s a preflight gate you run before you put a host on-chain or push a config change.

How does the projected outcome serve the Foundation’s mission of user-owned data?
Sia only works if hosts are reachable and stable. Misconfigurations reduce usable storage and create downtime + collateral risk for operators (and reliability risk for renters). hostd-guard reduces avoidable failures by catching common deployment mistakes before they affect renters or put host funds at risk.

We cannot provide grants to residents of jurisdictions under increased FATF monitoring, those that have active OFAC sanctions, or those that fail our bank compliance tests. We also cannot provide grants if your payment bank account is located in those same locations. Please review the following list.

Are you a resident of any jurisdiction on that list? Yes/No
No

Will your payment bank account be located in any jurisdiction on that list? Yes/No
No

GRANT SPECIFICS

Amount of money requested and justification with a reasonable breakdown of expenses:
$10,000 USD total (Small Grant).
Rate: $125/hour
Total: 80 hours

Breakdown:

  • CLI scaffold + config loading + report.json schema v1 (stable output shape): 10h = $1,250
  • Parsers: hostd.yml + docker-compose port mapping extraction + env overrides: 16h = $2,000
  • Core lint engine + stable rule IDs + deterministic ordering + remediation text: 18h = $2,250
  • Rule pack MVP implementation (ports, address sanity, admin API exposure, pricing/collateral sanity + tolerance): 20h = $2,500
  • SARIF output + GitHub Action wrapper + CI workflow template: 8h = $1,000
  • Fixtures + regression tests + quickstart docs/examples: 8h = $1,000
    Total: 80h = $10,000

Consider the following when submitting your budget.
The Foundation can only pay out grant funds in $USD via ACH or wire.
Grant payments will be made monthly.

What is the high-level architecture overview for the grant? What security best practices are you following? Please review our Development Guide for further details.
High-level architecture:

Inputs: hostd.yml, optional docker-compose.yml

Pipeline: parse → normalize → run rules → emit findings

Outputs:

  • report.json (stable schema, machine-readable)
  • report.sarif (optional, GitHub code scanning compatible)
  • console summary (short + actionable remediation steps)

Security best practices:

  • MVP is offline-only (no API password needed)
  • Explicit admin API exposure check for Docker/Compose (avoid binding 9980 publicly)
  • Outputs avoid dumping sensitive values by default (and can support redaction where needed)

What are the goals of this small grant? Please provide a general timeline for completion.
Goal: ship and field-test a practical MVP that host operators can run quickly to catch common host deployment misconfigs, and turn real-world failures into fixtures + rules.

Timeline : 1-2 months (8 weeks total) :

  • Week 1–2: CLI + parsers + baseline fixtures (good + obvious bad)
  • Week 3–5: Rule pack MVP + deterministic JSON output + remediation text
  • Week 6–7: SARIF + GitHub Action + expand fixtures from field testing feedback
  • Week 8: Release hardening (at minimum: go install + tagged release notes) + docs + final field-test report (what failures were most common + what rules were added)

What are your plans for this project following the grant?

  • Maintain the rule pack for at least 2–3 months after the final milestone (bugfixes + small updates as hostd config changes).
  • Keep a simple compatibility note in the README (tested hostd versions).
  • If adoption is strong, propose a follow-up Standard Grant to add stage gating improvements and optional read-only live checks using hostd endpoints (including connect-test), without turning it into a hosted service.

Potential risks that will affect the outcome of the project:

  • Committee prefers these checks inside hostd: mitigated by keeping this strictly external and workflow/CI-focused (no daemon changes needed).
  • Port/NAT forwarding is environment-dependent: mitigated by being explicit that MVP checks config/deploy intent, not actual internet reachability.
  • Rule drift as hostd evolves: mitigated by fixture-first tests and versioned releases.
  • Scope creep into monitoring/benchmarking/troubleshooting: mitigated by hard out-of-scope boundaries (no hosted service, no public scanning, no ranking).
  • Adoption risk: mitigated by keeping it simple (one command, clear fixes, GitHub Action template).

DEVELOPMENT INFORMATION

Will all of your project’s code be open-source?
Yes. All grant-funded code will be open-source. No closed-source components are planned. Any third-party libraries will be properly licensed and acknowledged.

Leave a link where code will be accessible for review.

Do you agree to submit monthly progress reports?
Yes. Monthly progress reports will be posted in the forum with milestone status, links to PRs/releases, and updated demo instructions.

CONTACT INFO

Email:
[email protected]

Any other preferred contact methods:
[x/twitter : @dappsoverapps

Hello @DappsoverApps, welcome to the Sia community!

Given you’re new to us, we will need you to start with a Small Grant and to show some proof of your previous work over GitHub.

For a Small Grant, the goal is:

To incentivize the creation and field testing of novel ideas and small utilities that add value to the Sia ecosystem.

Guidelines:

  • Project Budget: Up to $10,000 USD
  • Project Timeline: Up to three months from grant approval

You can find the proposal template for a Small Grant here.

If you wish this grant to be presented to the Grants Committee at next week’s meeting, please complete all edits by this Wednesday at 5pm ET.

1 Like

Hello @mecsbecs , thank you so much for the feedback. I have updated it. We would also be available for the meeting to present our project. Thank you.

The meeting is for review of your proposal. you presenting it is posting it here per grant program rules and getting community feedback and a decision. There is no zoom/meets etc involved here.

Kudos.

2 Likes

Thanks for these updates. And yes, as pcfreak30 said there is no requirement for you to actively present your proposal, this post is how the Committee will see it.

1 Like

Hi @pcfreak30 , thank you so much for the heads up. Good to know. Thank you.

Hi @mecsbecs. Thank you for the update.

Thanks for your proposal to The Sia Foundation Grants Program.

After review, the Committee has decided to reject your proposal citing the following reasons:

  • There is no proven need for this MVP from the Sia host community, especially given configuration issues for setting up hostd are minimal and easily noticed.
  • The repository provided as proof of previous work is listed under another username, making ownership of the work unclear.

We’ll be moving this to the Rejected section of the Forum. Thanks again for your proposal, and you’re always welcome to submit new requests if you feel you can address the Committee’s concerns.