Sell commercial package

Or host a private composer repo with a laravel/lumen endpoint to download the zips and using auth tokens per user. It's a bit involved but I for one prefer no 3rd party if I can prevent it.

Can you tell me more about?

You can take a look at how Nova does it.

https://nova.laravel.com/docs/2.0/installation.html#installing-nova-via-composer

@armancodes I saw packagist.com, but seem to me too much expensive (14euro/month/user)...

@sinnbeck I was asking myself how Nova manage selling, thanks for the link.

Seem that Nova allow to install using composer path (which is for now my primary way to handle this), and seem also that Nova use Satis, I already check into, but seem a bit complicated to setup, I didn't check into too much, but also found others claim the same.

Actually I used to use lumen to download packages via composer - now it's just based on basic auth

This is on my laravel composer

"repositories": [
    {
      "type": "composer",
      "url": "https://adomain.com/packages"
    }
  ]

packages.json on "adomain.com" example

{
  "packages": {
    "everserve/account": {
      "1.0.0": {
        "name": "everserve/account",
        "version": "1.0.0",
        "version_normalized": "1.0.0.0",
        "dist": {
          "url": "https://adomain/packages/everserve-account-v100.zip",
          "type": "zip"
        },
        "require": {
          "everserve/core": "^1.0",
          "everserve/database": "^1.0",
          "everserve/localization": "^1.0"
        },
        "autoload": {
          "psr-4": {
            "EverServe\Account\": "src"
          }
        },
        "extra": {
          "laravel": {
            "providers": [
              "EverServe\Account\ServiceProvider"
            ]
          }
        },
        "time": "2019-12-13 00:00:00",
        "type": "library"
      }
    },{...another package}
}

Using basic auth via htaccess inside /packages folder

AuthType Basic
AuthName "Restricted Content"
AuthUserFile "/var/www/html/adomain/public_html/packages/.htpasswd"
require valid-user

this will match the one in the .htpasswd of course.

When you do "composer require everserve/account" as example it will ask for credentials but you can also add a auth.json next to composer.json with something like

{
  "http-basic": {
    "client-2": {
      "username": "user",
      "password": "pass"
    },
    "client-1": {
      "username": "user",
      "password": "pass"
    }
  }
}

Hope it helps and I didn't forget a step, it took me a couple of days spitting through the composer docs to figure it out. But works a charm and zero dependencies - no pun intended :)

@artcore Thanks for sharing, I like the way you manage it with zero deps.

I think that using Lumen (or simple PHP) for download package would allow to add more logic, for example checking if customer has active subscription to allow download last upgrade or just last version that he buy. Or even use a license code instead of user/pass. Can you share setup in this case? If is too long, maybe just send me link of composer docs where I can read more about.

It's simply a case of having lumen for instance handle the download endpoint in stead of just having basic auth.

So the endpoint /packages would be a route with middleware whereas I'm simply using Apache without any php framework to serve it up.

The htaccess would still be used as a global auth after which the user policy kicks in and you test against user subscriptions using the username of the basic auth.

@artcore I got it, thanks for sharing. I will check into in next days. I will mark your as best answer but thanks also to others who reply since are valid answers, your solution sound just best for me.

@thewebartisan7 it's been a while since you posted this, but in case you are still looking for a solution. I launched Unlock.sh this year to help developers make a living selling their software. Private PHP composer packages are also supported ( https://unlock.sh/php-composer-packages )

Was looking for something like this. Thank you!