# Pinkary: A Laravel Link Hub and Community Platform > Pinkary is an open-source Laravel application for publishing personal link collections and interacting with like-minded people. It combines Livewire and Tailwind CSS with feeds, explore, questions, likes, MySQL persistence, queues, uploads, and email features. **pinkary-project/pinkary.com** — Create a landing page for all your links and connect with like-minded people without the noise. - Repository: https://github.com/pinkary-project/pinkary.com - Website: https://pinkary.com - Stars: 1,540 · Forks: 381 - Language: PHP - License: AGPL-3.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/pinkary-project-pinkary-com ## Why Pinkary exists Pinkary solves two related problems. Its original purpose is to give people one landing page for the links they want to share, avoiding the need to publish a separate page for every profile or topic. Its broader purpose is social discovery. The project adds a feed, explore area, questions, likes, and other community features so that a link collection can become a place for interaction. The intended users are people who want a public profile built around their links and who are interested in finding others with similar interests. The repository describes the product as a place to connect with like-minded individuals without the noise, so Pinkary is more than a bookmark list or a static link page. It is a Laravel application with both personal publishing and social-network functions. That distinction matters for adoption. A user who only needs a page of links may find the application heavier than necessary, while a community operator may value the feed and interaction model. ## Laravel, Livewire, and Tailwind architecture Pinkary is a regular Laravel application built on Laravel 13, with Livewire v4 and Tailwind CSS v4 for the frontend. The repository includes the standard Laravel structure: `app/`, `routes/`, `resources/`, `database/`, `config/`, `tests/`, and `public/`. The frontend package configuration uses Vite to build assets, Tailwind CSS for styling, and packages for forms, typography, Blade formatting, syntax highlighting, autosizing, notifications, sorting, Axios, and Alpine.js notifications. The application configuration indicates that MySQL is the default database driver, while sessions, cache, and queues can also use the database. Uploaded files use the public filesystem disk by default. Production deployments are documented as using Laravel Cloud, MySQL, and S3-compatible object storage. Mail is handled through Mailcoach according to the README, although local development defaults to the log mail driver. This is a conventional Laravel deployment model, which makes the source approachable for developers who already understand framework conventions. It also means that operation involves several moving parts rather than a single PHP process and static asset build. ## Installing Pinkary from the repository The README lists PHP 8.5 with MySQL, GD, and other common extensions, plus Node.js 26 or newer. Clone the repository and create a feature or fix branch before making changes. The documented branch name is only an example, so replace it with a branch name that describes the work. The README says not to push directly to `main`. ```bash git clone https://github.com/pinkary-project/pinkary.com.git cd pinkary.com git checkout -b feat/your-feature # or fix/your-fix ``` The automated setup command documented by the project installs and prepares the application. If you prefer the manual route, install the PHP and JavaScript dependencies separately. ```bash composer install npm install ``` After dependency installation, copy the example environment file, generate the Laravel application key, prepare the MySQL connection, run migrations, and expose uploaded files through the public storage link. ```bash cp .env.example .env php artisan key:generate php artisan migrate php artisan storage:link ``` The README documents `composer setup` as the automated alternative: ```bash composer setup ``` These commands do not remove the database and environment prerequisites. The `.env.example` file uses `DB_CONNECTION=mysql`, a local MySQL host, database-backed sessions, cache, and queues, and the public filesystem disk. A developer using the manual path must therefore prepare a reachable MySQL database before running the migration command. ## Running the first local Pinkary session The documented setup uses separate terminals for asset watching, queue processing, and the Laravel development server. Start the Vite watcher first, then run the queue worker and web server in separate terminals. The README says to run these separately. ```bash npm run dev ``` ```bash php artisan queue:work ``` ```bash php artisan serve ``` The exact URLs and ports are not documented in the installation instructions, so readers should use the output from these commands rather than assume a particular port. The default `.env.example` configures `APP_URL=https://pinkary.com`, local MySQL settings, database-backed sessions and queues, public file storage, and the log mailer. Production requires separate object storage configuration and a mail provider. The application is therefore not ready merely after dependency installation. A developer must prepare MySQL, run migrations, expose uploaded files, start the queue worker, and choose how email and storage will behave in the target environment. Local email is sent to the log driver by default, so the first local use does not require a functioning external mail service, although production email behavior must be configured separately. ## Testing, tooling, and maintenance cost Pinkary documents Pest as its test framework and PHPStan as its static analysis tool. It also uses Laravel Pint for Laravel code style and Rector to keep code updated with newer PHP versions. The README states that Pest's type coverage and the test suite are at 100% coverage, but it does not provide a coverage report or describe which behaviors are covered. Contributors can run the individual checks or the complete suite. ```bash composer lint composer test:lint composer refactor composer test:refactor composer test:types composer test:unit composer test ``` The `composer test` command runs all documented tools. The README states that pull requests that do not pass the test suite will not be merged. These requirements create a predictable contribution path, but a local developer needs the Composer and Node toolchains, a working database, and enough time to run migrations and checks. The project uses AGPL-3.0. That license matters for operators who modify or provide the application over a network, because the repository identifies the license as GNU Affero General Public License. Organizations should review the applicable source-code and network-use obligations with their own legal process rather than treating this article as legal advice. Maintenance activity is evidenced by a last push on 2026-10-15, after recent releases including v2.8.0 on 2026-10-11, v2.7.0 on 2026-09-23, and v2.6.1 on 2026-09-12. ## Operational limits of the Laravel design Pinkary is the wrong choice when the requirement is a small, static page containing links and nothing else. The repository describes a full Laravel application with social features, database-backed sessions, queues, migrations, uploaded files, mail handling, and production infrastructure. That architecture introduces operational work that a static site does not need. A team unwilling to run `php artisan queue:work`, configure a MySQL database, or manage public storage should look elsewhere. The repository does not document a rollback procedure, production deployment command, complete production `.env` checklist, or a full guide for operating Mailcoach and S3-compatible storage. Those omissions do not mean the features are absent, but they limit what can be confirmed from the project documentation. Pinkary may also be a poor fit for a deployment where the operator cannot manage application secrets, database backups, queued job failures, mail delivery, and uploaded-file storage. The repository layout shows a Laravel application with a Docker Compose file for a MySQL-backed development environment, but the README's primary local instructions use native Composer, NPM, Artisan, and Vite commands. ## Pinkary compared with a conventional link page A conventional link page stores or renders a list of URLs and may include basic metadata or an external analytics service. Pinkary keeps the link collection as the public identity of a user, then adds application-level social functions such as feed discovery, explore, questions, and likes. Its value is therefore not only link aggregation. The trade-off is system scope. A static page can be served as files or through a small web application, while Pinkary requires a Laravel runtime, MySQL, PHP and Node dependencies, queue processing, file storage, and application configuration. Pinkary is the more appropriate choice for an operator who wants to operate a community product. A static link page is easier to deploy when the only requirement is publishing URLs. The repository does not document a formal comparison with Linktree, Bento, or another named service, so the meaningful distinction here is architectural. Pinkary is a self-hosted Laravel community application, not just a hosted collection of outbound links. An organization that values social interaction may accept the extra infrastructure. An individual who only needs a public list of links may find that the database, queue, and application configuration are unnecessary. ## Pinkary adoption boundaries Pinkary suits developers and organizations that want a self-hosted link hub with social interaction and are prepared to operate a Laravel application. It does not suit a person seeking a zero-maintenance static profile, or a team that needs a documented turnkey deployment path but cannot provide MySQL, queues, storage, and email services. The first adoption checks are concrete: confirm PHP 8.5 and Node.js 26 are available, prepare the MySQL connection from `.env.example`, run the migrations, decide how uploaded files will be stored, and identify how queued jobs will be monitored. Review the AGPL-3.0 license and the production Mailcoach and S3-compatible storage requirements before deployment. If those conditions match, Pinkary provides a documented Laravel foundation for a link-centered social product. If they do not, the project is too broad for a simple link page. ## Conclusion Pinkary fits developers who want to self-host a link page and participate in its social features, especially teams already comfortable with Laravel, Livewire, MySQL, and queued jobs. It is a poor choice for a static link page, a deployment with no queue or object-storage plan, or operators unwilling to accept AGPL-3.0 obligations. Verify PHP 8.5 and Node.js 26 support, database and storage configuration, mail delivery, queue processing, and the AGPL-3.0 terms before adopting it. ## FAQ ### What is Pinkary used for? Pinkary provides a landing page for a user's links and a place to interact with like-minded people. The README also lists feed, explore, questions, and likes as features added over time. ### How do I install Pinkary locally? Clone the repository, install dependencies with Composer and NPM, copy `.env.example` to `.env`, generate the application key, configure MySQL, run migrations, and link storage. The README documents both `composer setup` and the manual sequence. ### What does Pinkary require to run? The README lists PHP 8.5 with MySQL, GD, and other common extensions, plus Node.js 26 or newer. Local operation also requires the documented Laravel processes: `npm run dev`, `php artisan queue:work`, and `php artisan serve`. ### What database and file storage does Pinkary use? The default environment config uses MySQL and the public filesystem disk. The production section states that Pinkary is hosted on Laravel Cloud with MySQL and S3-compatible object storage for uploaded files. ### What license does Pinkary use? Pinkary is licensed under the GNU Affero General Public License, identified in the repository as AGPL-3.0. Operators should review the license terms for their planned use and modifications. ## Sources - [License: AGPL-3.0](https://github.com/pinkary-project/pinkary.com/blob/main/LICENSE) - [pinkary-project/pinkary.com on GitHub](https://github.com/pinkary-project/pinkary.com) - [Project website](https://pinkary.com) - [README](https://github.com/pinkary-project/pinkary.com/blob/main/README.md) - [Releases](https://github.com/pinkary-project/pinkary.com/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pinkary-project-pinkary-com