README

The DBStan package provides detailed analysis and insights into your database schema for Laravel applications. It helps identify structural issues, missing indexes, normalization problems, nullable column risks, foreign key inconsistencies, and performance concerns.

It is an essential tool for debugging, optimizing, reviewing, and maintaining a healthy database architecture in Laravel projects.

Important Notice: Configure Database Before Using This Package

Before using this package, ensure your database connection is properly configured in your Laravel application.

If the database is not configured correctly, DBStan will not be able to analyze your schema.

Make sure your .env file contains valid database credentials.

Security Warning

This package exposes detailed database schema analysis.
It is intended for admin and development use only.

Do NOT expose this tool publicly in production without proper access restrictions, as schema details may reveal sensitive structural information.

#Laravel  #Database  #Schema  #PHP  #Performance  #Optimization  #Analysis

Documentation

Features

• Analyze full database schema structure
• Detect missing indexes on foreign keys and log tables
• Identify nullable column overuse and high NULL value ratios
• Detect normalization and integrity issues (duplicate rows, orphan risks, improper foreign key naming)
• Audit trail checks (created_by, updated_by, deleted_by columns)
• Detect repeated common fields across tables
• Identify tables with too many columns or wide VARCHARs
• Highlight performance risks (large TEXT columns, JSON overuse, unbounded growth, table size)
• Detect improper pivot table structures
• Identify enum and boolean overuse
• Detect mixed domain columns (e.g., info/data/details in varchar)
• Check for missing soft deletes and timestamps
• Detect status columns missing indexes
• Detect polymorphic relation overuse and missing indexes
• Lightweight and optimized for fast schema scanning
• Supports Laravel 9, 10, and 11 with PHP 8+ compatibility
• CLI-based analysis with structured categorized output

Supported Versions

• PHP: ^8.0
• Illuminate Support: ^9.0 | ^10.0 | ^11.0

Installation

To install the package, run:

composer require itpathsolutions/dbstan

Commands

Vendor Publish (Optional)

After installing the package, you may publish the configuration file using:

php artisan vendor:publish --tag=dbstan-config

This will create the configuration file at:

config/dbstan.php

You can customize thresholds like:

• Maximum columns per table
• Maximum VARCHAR length
• JSON column limits
• Large table size threshold
• Nullable ratio threshold

Run Analysis for Production

To analyze your database schema:

php artisan dbstan:analyze

or

http://127.0.0.1:8000/dbstan

These both scans your entire database and displays categorized results in the browser or terminal.

Export Report

Currently, DBStan displays analysis results in the terminal or browser.

Future versions may support exporting reports to JSON, HTML, or PDF formats.

Output Categories

DBStan organizes its findings into four main categories:

1. Structure Issues

• Tables with too many columns
• Wide VARCHAR fields
• Missing timestamps or soft deletes
• Boolean and enum overuse
• Nullable column overuse
• Large TEXT columns
• Data type appropriateness
• Mixed domain columns
• Repeated common fields across tables
• Pivot table structure issues

2. Integrity Issues

• Duplicate rows detection
• Foreign key naming inconsistencies
• Cascading action problems
• Possible orphan risks
• Unique constraint violations

3. Performance Issues

• Missing indexes on foreign keys
• Missing indexes on log tables
• Missing indexes on status columns
• High NULL value ratios
• Table size analysis
• Unbounded growth risks

4. Architecture Issues

• Audit trail implementation (created_by, updated_by, deleted_by)
• JSON column overuse
• Polymorphic relation overuse

Environment Configuration

Ensure your .env file contains:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=your_database
DB_USERNAME=your_username
DB_PASSWORD=your_password

After updating configuration:

php artisan config:clear

FAQs

1. What does this package do?

DBStan analyzes your Laravel database schema and detects structural, normalization, and performance issues.

2. Does it modify my database?

No. DBStan is completely read-only.
It does NOT make any changes to your database.

3. Is it safe for production?

Yes, but it is recommended to use it in development or staging environments.
Avoid exposing schema analysis publicly.

Contributing

Contributions are welcome!

If you’d like to contribute:

1. Fork the repository
2. Create a feature branch (git checkout -b feature/your-feature)
3. Commit your changes (git commit -am 'Add new feature')
4. Push to the branch (git push origin feature/your-feature)
5. Open a Pull Request

Please ensure:

• Your code follows PSR-12 coding standards
• All tests pass before submitting
• You include tests for new features

For major changes, please open an issue first to discuss what you would like to change.

Security Vulnerabilities

If you discover a security vulnerability within DBStan, please send an email to enquiry@itpathsolutions.com.

All security vulnerabilities will be promptly addressed.

For more details, see our Security Policy.

License

DBStan is open-sourced software licensed under the MIT license.

A couple of months ago, Eindhoven-based designer Paul Staal was thinking about a new project: a smart dashboard for his home office. His idea was to integrate the dashboard into a 3D-printed shell that paid homage to Lego’s classic 2×2 sloped computer brick, a piece that’ll be instantly recognizable to anyone who has spent any time with vintage Space Lego sets.

Eventually, Staal tells Gizmodo, he decided to combine the dashboard into a case for his Mac Mini: “[I thought], ‘Why would I add another device to my desk? Why not just make it large enough for my [computer] instead?’”

The original design stuck closely to that of the Lego brick, but Staal found the result “bland and boring”: without the detailing on the front of the brick, the case was essentially just a large right-angled triangle. But then inspiration struck: why not combine the Lego silhouette with the aesthetics of another 1980s design icon?

The result was the M2x2, a case that takes its inspiration from both Lego’s classic console brick and the original Apple Macintosh. It’s 3D printed with a filament that’s an absolute dead ringer for the latter’s beige plastic shell, and equipped with a 7” touch screen, multiple USB-C ports, an SD card reader, and a handle for portability.

The design is full of clever touches: for example, the two large studs atop the case are both functional, with one serving as a volume knob for Staal’s Bluetooth speaker and the other as a wireless charger for his AirPods and Apple Watch. (They’re also adorned with actual Lego studs that can accommodate a mini-figure—or, indeed, one of the bricks that served as the design’s inspiration.) Anyone else using the design can customize the functionality to their liking: “I made the design for this case modular,” Staal explains, “so if anyone wants to make one, they can choose what they want to use the studs for.”

The touchscreen, meanwhile, is essentially self-contained: “It offer[s] quick access to some controls on my Home Assistant dashboard.” Staal says that if he makes another version of the device, he’d perhaps replace it with an iPad Mini to take advantage of that device’s integration with macOS. “Maybe I’ll work on that in the future,” he says, “perhaps even pairing it with a Mac Studio instead of a Mac mini.”

For now, though, he has a couple of other projects on the go: “I have a couple of other projects that I still want to document/finalise and share on my website… One of them is a new dock for my Nintendo Switch 2, [which] I hope to finish somewhere in the upcoming weeks, so stay tuned.”

After three years of development and extensive production use, Workflow 3.0 brings significant improvements to building multi-step procedures in PHP. This release focuses on simplifying asynchronous execution, improving developer experience, and adding essential resilience features.

# Dependency injection

Version 3.0 introduces container support for injecting dependencies into jobs at runtime:

This enables workflows to remain stateless while accessing services like databases or HTTP clients through the container.

# Callable support

Version 3.0 accepts any PHP callable as a job, providing flexibility in how you define workflow steps:

This eliminates boilerplate for simple operations while maintaining support for Action classes when business logic requires full class structure. Callables enable inline data transformation without requiring dedicated action classes for single-use operations.

# Response property access

Version 3.0 extends response() to access public object properties directly, not just array keys:

This works transparently with both arrays and objects, allowing actions to return domain objects without requiring array conversion. The workflow engine inspects the response and accesses properties or array keys accordingly.

# Retry policies

Transient failures in distributed systems are inevitable. Workflow 3.0 implements configurable retry policies:

Retry policies are essential for handling transient failures in distributed systems, where network operations and external services may temporarily fail but succeed on subsequent attempts.

# True async execution

The parallel runner has been replaced with a true async implementation using AMPHP. This provides non-blocking execution without the overhead of process forking, leveraging PHP 8.1+ Fibers for efficient multitasking.

Independent jobs execute concurrently while the engine manages the resolution of the dependency graph. This follows asynchronous task-based execution model where the scheduler unrolls the graph and executes nodes as soon as their data dependencies (like response()) are satisfied. This shift significantly reduces memory footprint compared to the previous process-based model while maintaining strict execution order.

# Conditional execution

Version 3.0 adds withRunIfNot() for cleaner conditional logic:

This complements withRunIf() and accepts boolean literals, variables, job responses, and callables. Conditional execution enables branching without complex orchestration logic.

# Type safety

Integration with chevere/parameter 2.0 provides runtime validation:

Workflow validates inputs before job execution and verifies response types match expected parameters in dependent jobs. This eliminates a class of runtime errors that would otherwise require extensive testing.

# Practical example

Here’s a complete workflow for processing user uploads:

This workflow validates the file, resizes and optimizes it in parallel, then stores the result. The resize job retries on failure, and both processing jobs only run if validation succeeds.

# Migration notes

The parallel runner removal is the only breaking change. Applications using parallel execution should switch to async jobs with appropriate dependency declarations. The async runner provides better performance and simpler semantics.

# Conclusion

Workflow 3.0 represents three years of production refinement. The addition of container support, callables, retry policies, and true async execution address real-world requirements while maintaining the declarative approach that makes workflows maintainable.

The library continues following established patterns from workflow research and distributed systems literature. Each job remains independently testable, workflows stay declarative, and the dependency graph handles execution ordering automatically.

For complete documentation and examples, visit chevere.org/packages/workflow.

Ward, created by El Jakani Yassine is a command-line security scanner written in Go designed around Laravel’s structure. Rather than running generic pattern matching across your codebase, it first parses your project’s structure—routes, models, controllers, middleware, Blade templates, config files, environment variables, and dependencies—then runs targeted checks against that context.

Installation

Ward is distributed as a Go binary so you’ll need to ensure you Go already installed and then you can run:

go install github.com/eljakani/ward@latest
 
# Make sure $GOPATH/bin is in your PATH
export PATH="$PATH:$(go env GOPATH)/bin"

After installing, run ward init to create ~/.ward/ with a default config file, 42+ built-in rules organized by category, and directories for reports and scan history.

Scanning a Project

Point Ward at a local directory or a remote Git repository:

# Local project
ward scan /path/to/laravel-project
 
# Remote repository (shallow cloned)
ward scan https://github.com/user/laravel-project.git

When run in a terminal, Ward displays a TUI. A scan view shows pipeline progress and live severity counts as scanners run. Once complete, a results view presents a sortable findings table with severity badges, category grouping, and a detail panel showing descriptions, code snippets, and remediation guidance.

What It Checks

Ward ships with four independent scan engines:

• env-scanner runs 8 checks against your .env file, including debug mode enabled in production, missing or weak APP_KEY, and secrets leaked in .env.example.
• config-scanner runs 13 checks across your config/*.php files, covering hardcoded credentials, insecure session flags, CORS wildcard origins, and missing security options.
• dependency-scanner queries the OSV.dev advisory database in real time against your composer.lock to find vulnerable Packagist packages. Because it queries live data rather than a bundled list, it reflects current advisories rather than whatever was current at the tool’s last release.
• rules-scanner applies 42 rules across 7 categories: secrets (hardcoded passwords, API keys, AWS credentials), injection (SQL, command, eval), XSS (unescaped Blade output, JavaScript injection), debug artifacts (dd(), dump(), phpinfo()), weak cryptography (md5, sha1, insecure RNG), configuration issues (CORS, CSRF, mass assignment), and authentication gaps (missing middleware, absent rate limiting).

Output Formats

Configure output formats in ~/.ward/config.yaml:

output:
 formats: [json, sarif, html, markdown]
 dir: ./reports

• JSON — machine-readable results
• SARIF — compatible with GitHub Code Scanning and IDE integrations
• HTML — standalone dark-themed visual report
• Markdown — suitable for PR comments

CI/CD Integration

Ward returns non-zero exit codes when findings meet or exceed a specified severity, making it straightforward to gate deployments:

ward scan . --output json --fail-on high

A GitHub Actions example from the project’s documentation:

name: Ward Security Scan
on: [push, pull_request]
 
jobs:
 security-scan:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-go@v5
 with:
 go-version: '1.24'
 - name: Install Ward
 run: go install github.com/eljakani/ward@latest
 - name: Run Ward
 run: ward init && ward scan . --output json
 - name: Upload SARIF
 if: always()
 uses: github/codeql-action/upload-sarif@v3
 with:
 sarif_file: ward-report.sarif

Baseline Management

For teams that want to acknowledge existing findings without suppressing future ones, Ward supports a baseline workflow:

# Capture current state
ward scan . --output json --update-baseline .ward-baseline.json
 
# On subsequent runs, suppress known findings and fail only on new ones
ward scan . --output json --baseline .ward-baseline.json --fail-on high

Committing .ward-baseline.json to your repository lets the team track which findings have been acknowledged and catch regressions in CI.

Custom Rules

Drop .yaml files into ~/.ward/rules/ to define additional checks. Rules support regex or substring patterns, file-existence checks, and negative patterns that fire when something is absent—for example, flagging routes that lack @csrf. You can target PHP files, Blade templates, config files, environment files, routes, migrations, or JavaScript files.

rules:
 - id: TEAM-001
 title: "Hardcoded internal service URL"
 severity: medium
 patterns:
 - type: regex
 target: php-files
 pattern: 'https?://internal-service\.\w+'

Individual built-in rules can also be disabled or have their severity overridden in config.yaml without touching the rule files themselves.

Scan History

Ward saves each scan result to ~/.ward/store/, and on subsequent runs it surfaces a diff against the previous scan—for example, "2 new, 3 resolved (12→11)"—so you can track how your security posture changes over time.

Visit Eljakani/ward on GitHub to browse the source and get started.