TL;DR: SnapDeploy runs a bug bounty program that rewards any valid bug report — not just security vulnerabilities. Find a functionality bug, UI glitch, or performance issue and earn container hours or a free month on your plan. Submit through the dashboard, get reviewed within 7 working days.
Why a Different Kind of Bug Bounty
Most bug bounty programs focus exclusively on security vulnerabilities. They're run through platforms like HackerOne or Bugcrowd, require specialized security knowledge, and pay cash rewards ranging from $100 to $10,000+.
That model works well for large companies. But it excludes the developers who actually use the product every day and discover non-security bugs through normal workflows.
SnapDeploy takes a different approach: reward any valid bug report, regardless of category. Functionality issues, UI problems, integration failures, and performance defects all qualify if the report clearly demonstrates a reproducible problem.
What Qualifies as a Valid Bug
The program accepts five categories of bugs:
Functionality Bugs
Features that behave differently from their intended behavior:
- A deployment feature fails when configuration is valid
- A container action returns an unexpected error
- A dashboard action does not trigger the correct process
Security Issues
Security bugs are considered high priority:
- Authentication bypass vulnerabilities
- Data exposure through APIs or dashboards
- Injection vulnerabilities or permission flaws
Security reports require responsible disclosure — do not publish details publicly before the fix, and allow 30 days for remediation.
UI and UX Bugs
Interface problems that affect usability:
- Broken layouts in the dashboard
- Buttons that do not trigger actions
- Incorrect information displayed in status fields
Performance Problems
- Deployment operations that take unusually long
- Dashboard actions that time out
- Memory or resource leaks during runtime
Integration Bugs
- GitHub repository connection failures
- Webhook triggers not firing
- API inconsistencies between endpoints
What Does Not Qualify
- Bugs in your own application code
- Problems caused by user misconfiguration
- Feature requests or product suggestions (submit these through the feedback program instead)
- Already reported bugs
- Issues originating in third-party services
- Social engineering attempts
Reward Tiers
Not every bug has the same impact. Rewards are determined based on severity and report quality:
| Severity | Example | Typical Reward |
|---|---|---|
| Critical | Security vulnerability, data exposure | 1 month free on paid plan |
| High | Deployment failure, container runtime error | 25+ container hours |
| Medium | Dashboard feature not working, integration bug | 10–25 container hours |
| Low | UI typo, minor layout issue | 5 container hours |
Final reward amounts are determined by the QA and development teams after review. These ranges are approximate.
Factors used during evaluation:
- Whether the bug affects container deployment or runtime
- Whether the issue impacts security or data access
- Whether the bug blocks normal platform usage
- How easily the bug can be reproduced
- The clarity and completeness of the bug report
How to Submit a Bug Report
Step 1: Document the Bug
Before submitting, collect the necessary information:
- Steps to reproduce the issue
- Expected behavior vs. actual behavior
- Browser and operating system details
- Container ID (if applicable)
- Timestamp of the occurrence
Step 2: Submit Through the Dashboard
Navigate to Dashboard → Report Bug to open the submission interface.
Step 3: Use the Bug Report Template
A structured report helps reviewers reproduce the issue quickly:
Summary: [One-line description]
Steps to Reproduce:
Go to…
Click on…
Enter…
Observe…
Expected Behavior: [What should happen]
Actual Behavior: [What actually happens]
Environment:
Browser: Chrome 120 • OS: macOS Sonoma • Container ID: cnt_xxxxx • Plan: Free tier
Step 4: QA Review
The QA team reviews the report, attempts to reproduce the issue, and may request clarification.
Step 5: Development Team Evaluation
After QA confirmation, the development team evaluates severity, assigns priority, and determines the reward level.
Step 6: Reward Credit
If accepted, rewards are typically credited within 7 working days. You'll receive an account credit and email confirmation.
Example Bug Reports
High Severity Example
Summary: Container logs show 0 bytes while container is actively producing output
Steps: Create a Node.js container → Deploy → Open Logs tab → Log panel shows "0 bytes" → Refresh → Still 0 bytes
Expected: Real-time console output in the logs panel
Actual: Log panel displays "0 bytes" even though the container is running
Environment: Chrome 120, macOS, Free tier, cnt_abc123Typical reward: 25+ container hours
Low Severity Example
Summary: Typographical error in deployment success message
Steps: Deploy any container → Wait for completion → Message shows "Containter deployed"
Expected: "Container deployed"
Actual: Spelling error in message textTypical reward: 5 container hours
How This Differs from Traditional Bug Bounties
| Aspect | Traditional Bug Bounties | SnapDeploy Bug Bounty |
|---|---|---|
| Scope | Security vulnerabilities only | Any valid bug |
| Rewards | Cash payouts ($100–$10,000+) | Container hours or 1 month free |
| Audience | Security researchers | Everyday developers |
| Complexity | Complex submission process | Simple dashboard form |
| Review speed | Often weeks or months | Typically 7 working days |
This lowers the barrier to participation. Developers who use the platform naturally encounter edge cases during real projects. Those discoveries now translate into rewards.
Bug Bounty vs. Feedback Rewards
SnapDeploy also runs a separate feedback rewards program for general platform feedback. The key difference: bug bounty is for reproducible software defects with higher rewards, while feedback rewards cover suggestions, praise, or general UX observations and earn approximately 5 hours per submission. Both programs reward users, but documented, reproducible bugs earn more.
Tips for Better Bug Reports
- Be specific. "Deploy button not working" is less helpful than describing the exact conditions under which the button fails
- Provide reproducible steps. The QA team should be able to follow the same steps and observe the issue
- Include environment details. Browser version, OS, and plan level can affect behavior
- Check if the bug is already known. Duplicate reports may not qualify
- Submit one bug per report. Multiple issues in a single report make review more difficult
Getting Started
The process is simple: find a bug, document it clearly, submit a report. If you're already using SnapDeploy, you're in the best position to find issues.
Report bugs through the SnapDeploy dashboard and earn rewards while helping improve the platform.
Learn more about the feedback rewards program • Review troubleshooting resources • Contact support
Top comments (0)