You push your Laravel project to production. Everything works fine for weeks. Then suddenly, performance slows down, queries start lagging and debugging turns into a detective job.

After hours of digging, you discover the real issues:

• A foreign key column without an index
• A table with 35 columns
• Prices stored as integers
• A VARCHAR (255) column that never needed to be that wide
• Tables missing timestamps

None of these are dramatic bugs. But together, they quietly damage database performance, maintainability and scalability.

That’s exactly the kind of problem DBStan was built to solve.

Instead of discovering database issues months later, DBStan analyzes your schema in minutes and flags structural, performance and architectural problems before they become production incidents.

What Is DBStan?

DBStan is a Laravel database schema analyzer that performs a comprehensive read-only inspection of your MySQL database structure. It detects design issues, missing indexes, performance risks and schema inconsistencies automatically.

The package is developed by IT Path Solutions and designed for Laravel developers, database administrators and DevOps teams who want better visibility into their database structure.

Think of it like PHPStan for your database schema.

Instead of analyzing PHP code, it analyzes how your database tables, indexes and relationships are structured.

The tool runs a full Laravel database architecture analysis. It produces a categorized report to help developers improve schema quality.

Technical Requirements

Component	Requirement
PHP	^8.1 | ^8.2 | ^8.3 | ^8.4
Laravel	^9.0 | ^10.0 | ^11.0 | ^12.0
Database	MySQL
Package Manager	Composer
Frontend Dashboard	Bootstrap 5.3.2 (CDN), Bootstrap Icons
License	MIT

These requirements allow DBStan to work across modern Laravel projects without additional dependencies.

The Real Problem

Common Database Mistakes Developers Make

Even experienced developers unintentionally introduce database design issues during development.

Laravel migrations make database creation easy, but that convenience sometimes hides structural problems.

Here are a few common mistakes DBStan catches automatically.

Missing Indexes on Foreign Keys

A column like user_id without an index might work fine initially. But once your application grows, query performance starts to degrade.

Prices Stored as INT Instead of DECIMAL

Storing monetary values as integers often causes rounding problems and inconsistent calculations.

Tables Without Timestamps

Laravel relies heavily on created_at and updated_at. Missing timestamps reduces traceability and data tracking.

Overusing VARCHAR (255)

Many developers default to VARCHAR (255) for almost everything. In reality, most fields don’t need that much space.

Weak Foreign Key Rules

Foreign keys without cascading rules can leave orphaned data after deletions.

Missing Soft Deletes

Critical tables without deleted_at make recovery impossible. Accidentally removed data cannot be restored.

These kinds of schema design issues accumulate quietly over time.

A Laravel database analysis tool like DBStan scans your entire schema and surfaces these risks instantly.

How DBStan works Internally

DBStan performs a read-only inspection of the database by querying MySQL metadata tables and Laravel’s database connection layer.

Internally, the analyzer collects schema information using:

• information_schema.tables
• information_schema.columns
• information_schema.statistics
• SHOW INDEX
• SHOW CREATE TABLE

This metadata is then passed through a set of modular rule checks that analyze:

• column types
• index coverage
• table width
• nullable ratios
• foreign key relationships
• storage size

Each rule produces a Finding object containing:

• severity
• description
• affected table
• suggested improvement

These findings are aggregated and displayed in two places:

This rule-based architecture makes DBStan easy to extend with custom checks.

How DBStan Helps

Four Categories of Database Checks

DBStan performs 26 automated checks grouped into four categories.

Instead of presenting raw database metadata, it translates technical issues into clear findings developers can act on.

1.Structure Checks

Is your table design clean?

Structure checks focus on table design, column types and schema conventions.

Examples include:

Check Name	What It Detects	Severity
Too Many Columns	Tables exceeding max_columns (default 25)	WARNING
Wide Varchar Columns	VARCHAR columns wider than 190	WARNING
Missing Timestamps	Tables missing created_at / updated_at	BEST PRACTICE
Missing Soft Deletes	Tables missing deleted_at column	BEST PRACTICE
Nullable Column Overuse	Columns marked nullable without justification	NULLABLE
Large TEXT Columns	Columns using TEXT type	PERF RISK
Data Type Appropriateness	“price” columns stored as INT not DECIMAL	DATA TYPE
Enum Overuse	Tables with >2 ENUM columns or ENUMs with >5 values	ENUM OVERUSE
Boolean Overuse	Tables with >4 boolean columns	ARCH WARNING
Pivot Table Structure	Pivot tables with unnecessary id or timestamps	PIVOT
Repeated Common Fields	Common field names across tables	REPEATED FIELD
Mixed Domain Columns	VARCHAR columns named “data”, “info”, “details”	DOMAIN MIX

These checks help enforce Laravel schema best practices, ensuring tables remain readable and maintainable.

2. Integrity Checks

Is your data safe?

Integrity checks verify relationships, constraints and data consistency.

Examples include:

Check	What It Detects	Severity
Foreign Key Naming	Columns like userid instead of user_id	NAMING
Duplicate Rows Risk	Tables without primary or unique keys	DATA INTEGRITY
Orphan Risk	_id columns without foreign key constraints	ORPHAN / HIGH RISK
Cascading Rules	Foreign keys using restrictive delete rules	INTEGRITY
Unique Constraint Violations	Duplicate values in email or slug columns	UNIQUE VIOLATION

These issues often go unnoticed until real data inconsistencies appear.

A Laravel database schema analyzer like DBStan identifies them early.

3. Performance Checks

Will your database scale?

Performance issues rarely show up during development. They appear when real traffic hits your application.

DBStan includes several checks focused on database performance.

Examples include:

Check	What It Detects	Severity
Missing Foreign Key Indexes	_id columns without indexes	ERROR
Large Table Size	Tables exceeding storage thresholds	SIZE ALERT
High NULL Ratio	Columns filled mostly with NULL values	DATA QUALITY
Status Column Indexing	Unindexed state or status columns	PERF
Log Table Indexing	Log tables missing indexes on created_at or user_id	PERFORMANCE
Unbounded Growth Risk	High-growth tables lacking indexing	GROWTH RISK

These checks form the core of DBStan’s Laravel database performance analysis, helping developers identify scalability risks early.

4. Architecture Checks

Are you designing for the long term?

Beyond structural and performance checks, DBStan also evaluates architectural patterns.

Examples include:

Check	What It Detects	Severity
JSON Column Overuse	Tables with too many JSON columns	WARNING
Audit Trail Check	Missing created_by, deleted_by or updated_by fields	AUDIT
Polymorphic Relation Overuse	Excessive polymorphic relationships	ARCH RISK

These checks help teams evaluate long-term maintainability and overall schema architecture.

Installation and Quick Start

Getting started with DBStan takes less than two minutes.

Step 1 – Install the Package

composer require itpathsolutions/dbstan

Step 2 – Run the Analysis

php artisan dbstan:analyze

DBStan scans your entire database schema and runs all enabled checks automatically.

Step 3 – Open the Web Dashboard

http://localhost:8000/dbstan

The dashboard provides a visual interface for exploring issues found during analysis.

What the Output looks like

DBStan prints a list of findings grouped by severity. This happens when you run the CLI command.

A typical report might look like this:

⚠️ WARNING – Table `orders` has 32 columns (exceeds limit of 25)

❌ ERROR – Column `user_id` in `posts` has no index

✅ BEST PRACTICE – Table `users` is missing `deleted_at`

All are categorized with a severity level. This helps developers know what to fix first.

Severity types include:

Label	Meaning	Action
ERROR	Critical schema problem	Fix immediately
WARNING	Design concern or anti-pattern	Review and address
BEST PRACTICE	Improvement recommendation	Consider adopting
PERFORMANCE	Potential performance bottleneck	Add index or optimize
HIGH RISK	Data integrity at serious risk	Fix immediately
SIZE ALERT	Table storage exceeds threshold	Archive/partition/optimize
NAMING	Column naming convention violation	Rename column
AUDIT	Missing audit trail columns	Add audit columns

This structured output turns raw schema inspection into actionable insight.

Web Dashboard for Visual Analysis

While the CLI command is useful for quick checks, DBStan also includes a web dashboard.

The dashboard is available only in local or staging environments, keeping production environments secure.

The interface includes:

• A left sidebar with category tabs
• Issue counts for each category
• Collapsible cards showing detailed findings
• A summary of schema problems

This makes DBStan useful not only for developers but also for teams reviewing database architecture together.

Securing the Dashboard

Because DBStan exposes schema information, the dashboard is intentionally restricted.

By default:

• The /dbstan route is disabled in production
• It works only in local or staging environments

For staging environments, you can add additional protection such as:

• authentication middleware
• IP whitelisting
• admin-only access

These safeguards prevent schema information from being exposed publicly.

Configurable for your Project

Every Laravel project has different database needs.

DBStan includes a configuration file that allows developers to customize thresholds and checks.

You can publish the configuration file using:

php artisan vendor:publish –tag=dbstan-config

Configuration options include:

Key	Type	Default	Description
max_columns	int	25	Tables with more columns trigger warning
max_varchar_length	int	190	VARCHAR columns wider trigger warning
max_json_columns	int	2	Tables with more JSON columns trigger warning
large_table_mb	int	100	Tables larger (MB) trigger size alert
null_ratio_threshold	float	0.5	Columns with NULL > ratio trigger warning
enabled_checks	array	all four	Remove a category to skip its checks

This flexibility makes DBStan a practical Laravel database optimization tool that can adapt to different application architectures.

Who should use DBStan?

DBStan is useful for more than just Laravel developers.

Solo Developers

Run it before deployment to catch schema issues early.

Development Teams

Use it during code reviews to enforce database standards.

DevOps Engineers

Integrate it into CI pipelines as part of automated quality checks.

Database Administrators

Audit existing Laravel databases for structural problems.

Open-Source Maintainers

Ensure consistent database architecture across contributors.

What DBStan does NOT do

To keep the tool safe and predictable, DBStan intentionally avoids certain actions.

It:

• does not modify your database
• supports MySQL only
• keeps the web dashboard disabled in production
• does not auto-fix issues

Instead, it focuses on reporting and analysis so developers remain in full control.

What’s Beneath the Code?

Your application logic can change. Your UI can evolve.

But your database schema becomes the foundation everything depends on.

Once bad design decisions enter production, fixing them becomes expensive.

DBStan helps teams run a quick Laravel database architecture analysis, identify schema problems early and maintain a healthier database structure over time.

If you’re serious about database quality, run your first analysis today.

You might be surprised by what your schema reveals.

GitHub: itpathsolutions/dbstan
Install: composer require itpathsolutions/dbstan

Your Laravel database deserves the same level of analysis as your code.

Run your first analysis in minutes!

Frequently Asked Questions

Does DBStan modify my database?

No. DBStan is completely read-only. It only reads schema metadata and row counts from your database to analyze structure, relationships and indexes. It never inserts, updates or deletes any data.

Is DBStan safe to run in production?

Yes. The Artisan command can safely run in any environment, including production.

However, it’s recommended to avoid running it during peak traffic because some checks query information_schema and table statistics, which may add minor overhead.

Also, the web dashboard is automatically disabled in production to prevent exposing database structure publicly.

Which databases are supported?

At the moment, DBStan supports MySQL only.

The analyzer relies on MySQL-specific commands such as:

• SHOW TABLES
• SHOW COLUMNS
• SHOW INDEX
• information_schema

Support for other databases may come in future versions.

Can I create my own custom checks?

Yes. DBStan is designed to be extendable.

You can create custom checks by adding a class inside the src/Checks/ directory and:

1. Extending BaseCheck
2. Implementing the required methods:
   a. run()
   b. name()
   c. category()

DBStan automatically discovers new check classes, so you don’t need to manually register them.

Can specific checks or categories be disabled?

Yes. DBStan allows you to control which checks run.

Open the configuration file:

config/dbstan.php

Inside the enabled_checks array, you can include only the categories you want to run. You might choose structure or performance or integrity or architecture.

This makes it easy to tailor the analysis according to the needs your project.

Why am I seeing issues on Laravel’s default tables?

DBStan scans every table in the database, including Laravel’s default tables like jobs, failed_jobs or password_resets.

Some checks may flag these tables for things like: missing timestamps, missing soft deletes, column structure warnings.

These warnings are meant for information. Use your own judgment before acting on them.

The /dbstan dashboard is not loading. What should I check?

If the dashboard route is not loading, check the following:

1. Make sure your .env file has
   APP_ENV=local or APP_ENV=staging
2. Clear cached configuration and routes
   php artisan config:clear
   php artisan route:clear
3. Confirm the package is installed
   composer show itpathsolutions/dbstan
   Once these are verified, the dashboard should load at:
   http://localhost:8000/dbstan

A complete Laravel application security blueprint covering authentication hardening, input validation, dependency auditing, CSP headers, secrets management, and CI/CD security scanning.

Laravel ships with strong security defaults. CSRF protection is built in. Password hashing uses bcrypt by default. Mass-assignment protection requires explicit fillable declarations. Most common web vulnerabilities are addressed out of the box if you use the framework as intended.

Enterprise applications need more than defaults. They need a layered security architecture that covers authentication hardening, input validation at every layer, dependency vulnerability management, secrets management separate from code, security headers, and automated security scanning in CI/CD. This article gives you that blueprint.

---

The Security Layers

A Quick Answer

A complete security blueprint for enterprise Laravel covers six layers: Authentication hardening (MFA, session management, Sanctum token rotation) Input validation at every layer (Form Requests, type declarations, parameterised queries) Dependency vulnerability management (composer audit, automated scanning) Secrets management (environment-based, rotated, never in code) Security response headers (CSP, HSTS, X-Frame-Options) Automated static analysis (Enlightn, Psalm, PHPStan) in CI/CD.

Layer 1: Authentication Hardening

Multi-Factor Authentication

Password-only authentication is insufficient for enterprise applications. Implement TOTP-based MFA using the pragmarx/google2fa-laravel package or the Spatie/laravel-google-authenticator equivalent. For higher assurance, WebAuthn hardware key support is available via the asbiin/laravel-webauthn package. Enforce MFA for administrative roles at minimum; consider enforcement for all users in high-risk applications.

Session Security

Configure session settings in config/session.php for production: encrypt=true (encrypts session payload at rest in Redis), secure=true (HTTPS-only cookies), same_site=strict (prevents CSRF via cross-site requests), http_only=true (prevents JavaScript access to session cookies). Set an appropriate session lifetime — not indefinite. Implement session invalidation on password change.

Account Lockout Policy

Laravel’s built-in RateLimiter can implement account lockout. After five failed login attempts within ten minutes from a specific IP plus email combination, lock the account temporarily. Log the lockout event. Alert the account owner via email. This prevents credential stuffing attacks without creating excessive friction for legitimate users.

Sanctum Token Security

For API authentication with Sanctum: implement token rotation (new token issued on each authentication, old token revoked), set token expiry via the expiration configuration, use token abilities to scope permissions per token, and log all token creation and revocation events.

Layer 2: Input Validation at Every Layer

HTTP Layer: Form Requests

Create a Form Request class for every controller method that accepts input. Never use $request->all() or $request->input() without explicit validation rules. Form Requests enforce validation before the controller method is called and provide a clean, testable location for validation logic. Validate strictly — use ‘required’, ‘string’, ‘max:255′, ’email:dns’ rather than permissive rules.

Application Layer: Typed Parameters

Service class methods should use typed parameters (string, int, float, bool, or Value Objects) rather than accepting raw arrays or mixed types. PHP 8.1’s readonly properties and enums provide additional type safety at the service layer. Typed parameters prevent class of injection attacks that bypass HTTP-layer validation.

Database Layer: Parameterised Queries Only

Eloquent’s query builder uses parameterised queries by default — SQL injection is prevented if you use the ORM correctly. The danger points are: raw query methods (DB::statement(), DB::select() with string interpolation), whereRaw() and orderByRaw() with user-controlled values, and direct use of $request->input() in query strings. Never interpolate user input into raw SQL expressions.

Layer 3: Dependency Vulnerability Management

Third-party packages are a significant attack surface. The 2021 Log4Shell vulnerability and numerous npm/Composer package vulnerabilities demonstrate that supply chain attacks are real and impactful.

composer audit

Run composer audit as part of every CI/CD pipeline. It queries the Packagist security advisories database and reports known vulnerabilities in installed packages. A build with known high-severity vulnerabilities should fail. Add composer audit –no-dev to your deployment pipeline — it checks production dependencies only.

Automated Dependency Updates

Use Dependabot or Renovate to automate minor and patch version updates for Composer packages. Configure review requirements for major version updates. Keeping dependencies current reduces the vulnerability window between package vulnerability disclosure and application update.

Layer 4: Secrets Management

Secrets — API keys, database credentials, encryption keys, third-party service tokens — must never live in code or version control. The .env file is a local development convention; it is not a secrets management system.

Production Secrets Management

For AWS deployments: AWS Secrets Manager with IAM role-based access. Secrets are fetched at application bootstrap and injected as environment variables. Rotation policies rotate credentials automatically without code changes. For non-AWS deployments: HashiCorp Vault provides equivalent functionality. For Kubernetes deployments: Kubernetes Secrets with sealed-secrets for encrypted storage in version control.

Secret Rotation Policy

Set rotation periods for all secrets: database passwords quarterly, API keys on any team member departure, encryption keys annually with key derivation function to transition encrypted data. Document the rotation procedure and test it — a rotation policy that has never been executed in testing will fail when executed under incident pressure.

Layer 5: Security Response Headers

Content Security Policy (CSP)

CSP is the most effective defence against Cross-Site Scripting (XSS) attacks that bypass CSRF protection. A CSP header tells the browser which sources of scripts, styles, images, and other content are permitted to load on your pages. Inline scripts from attacker-injected content are blocked even if the injection bypasses server-side sanitisation.

Spatie’s laravel-csp package provides a clean interface for building and testing CSP headers in Laravel. Start with a report-only CSP (violations are reported but not blocked) to identify legitimate inline scripts before enforcing. Enforce with strict-dynamic and nonce-based script loading.

HSTS, X-Frame-Options, and Referrer-Policy

Add a security headers middleware to your HTTP kernel: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload (HTTPS enforcement). X-Frame-Options: DENY (clickjacking prevention). X-Content-Type-Options: nosniff (MIME-type sniffing prevention). Referrer-Policy: strict-origin-when-cross-origin (referrer privacy). These four headers together close the most common browser-level attack vectors.

Laravel Security Audit We run a scored security audit on your existing or planned Laravel application. Request Security Audit

Layer 6: Automated Static Analysis

Enlightn

Enlightn is a Laravel-specific security and code quality analyser. Run php artisan enlightn to get a scored report covering: exposed debug information, CSRF configuration, CORS misconfiguration, SQL injection risk patterns, mass assignment vulnerabilities, and insecure session configuration. Integrate into CI/CD with a minimum score threshold.

PHPStan and Psalm

PHPStan and Psalm perform static type analysis, catching type errors, undefined method calls, and logic errors before they reach production. At level 6 or above, PHPStan catches the majority of type-related bugs that would otherwise manifest as runtime errors. Add to CI/CD as a blocking check.

Conclusion

Security is a layered discipline. No single control is sufficient, and the most sophisticated attack surface protections are irrelevant if MFA is not enforced or if secrets live in the codebase. Work through the six layers in order – authentication hardening and input validation deliver the most impact per hour of effort. Our Laravel development services include security architecture review and Enlightn-scored security audits on all enterprise engagements.

FAQ’s

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.”