Who needs a EULA if nobody reads it?

bintray_eula_products_blogpostAs long as you’re distributing public open source software, you don’t need a EULA. Just choose from the over 100 open source licenses Bintray offers to get the level of protection you want. Once you move to distributing commercial software, you need a EULA. This is the contract that you make with all of your users when they download your software from Bintray. Without a EULA, you’re exposing yourself to lawsuits and unmitigated copying and redistribution.

Now, we’ve all seen EULAs. Whether they’re entitled “Terms of Service”, “Terms and Conditions”, or “Here’s what you can and can’t do with my software”, essentially, they are the same. They usually pop up early on in the installation sequence of any new piece of commercial software we install. And I can tell you, with 5-nines of certainty that most of us just click “Next” without reading them, and complete the installation. But there is a breed of people who actually DO read EULAs. They are usually sequestered in some corporate enclave, and it’s their job to make sure that the company they represent can accept the contractual obligations you set forth in your EULA. Yes, these are the company lawyers. Without their “OK”, your potential enterprise customers will not use your software.

Now, as smart as lawyers may be (or not), if your EULA is hidden somewhere deep under /etc/this/that/and/the/other, it’s going to be difficult to find. There’s no reason to make this difficult. Bintray gives you an easy way to expose your EULA through Products.

Bintray Products and EULAs

Say you developed your “packageOfTheCentury”, and, naturally, you want to offer it to developers on different platforms. I.e., you might have your debianPackageOfTheCentury, nugetPackageOfTheCenutury, npmPackageOfTheCentury…and so on. Since all these packages represent the same product, just for different packaging formats, you will want to apply the same EULA to all of them. This is where Bintray Products come into play. Products are available with a Gold or Enterprise account, and let you collect all the packages under one roof as a single coherent offering, making it easy for you to manage. It’s also easier for potential users to find your single product rather than searching for all its components separately, and any update you make to any of the constituent packages in your product is automatically reflected as a new version of the product itself. But the biggest benefit is that you only need to assign a single EULA to your product, and it applies to all of its constituent packages. And the beauty of it is that your EULA protects your product, for both authenticated and anonymous users, before it’s even downloaded, rather than being embedded inside the packages. That also means that it’s easy to update online as any of the constituent packages are updated with new versions. 

Creating a Product is easy.

NewProduct

 

And once your product is created, and you’ve entered its basic details, it’s easy to add packages to it.

ProductPackages

You don’t even have to change your product’s version manually; it is automatically derived by Bintray any time the version of one its constituent packages changes. And if you really want to, you can assign a different EULA to different versions of your product as needed.You don’t even have to change your product’s version manually; it is automatically derived by Bintray any time the version of one its constituent packages changes. And if you really want to, you can assign a different EULA to different versions of your product as needed.

Product Versions

 

All About Bintray EULAs

With a Bintray Enterprise account, you can manage all of your EULAs in one place and set a default EULA to be assigned to all new versions of this product that are created.

ProductEULAs

You can create a new EULA at any time using Asciidoc, Markdown or free text.

Create a New EULA

And once you have a EULA assigned to your product, if anyone (even an anonymous user) tries to download a file from one of the packages in your product, they will have to accept your EULA first. In fact, the download URL provided by Bintray for any of the packages in your product will first pop up the EULA and require the user to accept before proceeding with download. That means you can provide a EULA-protected download link from any other app. Just hover over the package in your download list to see it.

Download URL with EULA

 

Why don’t you try this one to see how it works. Here’s what you should see.

Accept EULA

 

By collecting the different packages you are offering under a single product, governed by a single EULA, you’re protecting your interests, making things simpler, and reducing your (and your customers’) legal costs. Can you think of any better way to protect your IP and keep both your lawyers and your customers happy?

Read all about managing products and EULAs.

 

 

6 Reasons to Distribute Commercial NuGet Packages through Bintray

Developing on .NET? Then, most likely, you are no stranger to NuGet Gallery. It’s a great place to find public NuGet packages. But is it the best place to host and distribute your own private packages? With the recent addition of native support for NuGet, you can now point your NuGet client to Bintray and transparently use it as your download source for NuGet packages. In this post, I’ll show how Bintray complements NuGet Gallery and the benefits it offers for the commercial distribution of private and public NuGet packages.

Privacy with fine-grained access control

With a professional account on Bintray, you can create private repositories and set up teams of users with different permissions according to the access you want to provide each team. Using keys and entitlements, you can provide external users who don’t have a Bintray account access at any level of granularity, from a whole repository down to a single artifact.

Metadata

On Bintray, every package is accompanied with a variety of metadata that can be used to search for and download packages. These include owner, open-source licenses used by the package, link to version control where the package’s sources can be found, even user-defined attributes and more.

Rapid downloads

Bintray is deployed on US, European, and Asian clusters and provides ultra-fast downloads over a rapid CDN (Akamai and Cloudfront).

Rich stats and logs

Rich stats provide detailed download information over any time period, and live logs provide detailed information about who is accessing your packages.

Integration with Artifactory

Bintray’s tight integration with Artifactory means that you can fully automate your .NET development pipeline from development to distribution.

A universal distribution hub

Bintray can serve your enterprise distribution needs for all package types. In addition to NuGet, Bintray also offers native level support for Docker, Debian, Maven, RPM, and Vagrant packages. This means that Bintray maintains metadata specific to these package types and can work transparently with the corresponding clients.

How does it work?

It’s pretty simple really.

First, create a repository and specify its type to be NuGet.

Create a NuGet repository

Now, all you need to do is point your NuGet client or Visual Studio at your new repository on Bintray. That’s just as easy, and Bintray even shows you how to do that. On your new repository page, just click Set Me Up. For the sake of readability, on this post, I’ll be using the NuGet client.

Set up a NuGet Repository

So, like the Set Me Up dialog shows us, to configure the NuGet client to work with Bintray, you need to add Bintray to the client’s list of sources:

nuget sources Add -Name Bintray -Source https://api.bintray.com/nuget/jaycroaker/MyNugetRepo -UserName <USERNAME> -Password <API KEY>

 

As you can see, you’ll need to include your Bintray username and API Key.

Then, you need to enable the use of your Bintray API key with the NuGet client:

nuget setapikey <USERNAME>:<APIKEY> -Source Bintray

 

Now you’re ready to deploy packages from the NuGet client directly to bintray. As an example, let’s say you want to upload a great logging utility you created called MyLogger (yes, I’m keeping things simple). Are you used to using nuget push? Well, nothing has changed:

nuget push MyLogger.1.0.0.0.nupkg -Source https://api.bintray.com/nuget/jaycroaker/MyNugetRepo

 

Now you should be able to see your package in your new NuGet repository, complete with the version you assigned.

Resolving NuGet package

And resolving the NuGet package from Bintray with the NuGet client is just as easy:

nuget install MyLogger -Source https://api.bintray.com/nuget/jaycroaker/MyNugetRepo

 

As you can see, once you have added Bintray as a source for your NuGet client, you can push and install transparently as if you were working with the NuGet Gallery. And since Bintray is a universal distribution hub, you can push to and pull from Bintray with the same ease when working with Docker, Debian, RPM, Maven, and Vagrant using the corresponding client for those package types. And with generic repositories on Bintray, you can host generic distributions such as installers or data files with the same ease of use. As we continue to add support for more and more package types, working with Bintray will just continue to get easier.

Manage your Bintray and GitHub organizations better together

Bintray’s integration with GitHub is now moving to a new level with GitHub organizations! As a Bintray user who is also a GitHub user, you already know that you can import your GitHub repositories, tags, readme’s, and release notes to Bintray. Now you can also import your GitHub organizations, the organization’s repositories, and even keep your GitHub and Bintray organization’s members in sync! This new feature saves time and effort maintaining your organizations and their members across the two platforms.

Here’s how to do that:

Authorize your GitHub account in Bintray

In order to be able to import GitHub entities to Bintray, your GitHub account should be authorized in Bintray. Your GitHub username has to be provided and authorized in the ‘Accounts’ page in your Bintray profile page:

Authorize Github in Bintray

Grant Bintray access to your GitHub organizations

GitHub organizations should be authorized with Bintray, so Bintray is able to access your GitHub organization. Grant Bintray the access by going to your GitHub profile. Under the ‘Applications’ section you will see the GitHub organization. Select the organizations you would like Bintray to be able to access.

GHOrganizationAccess

You can read more about application authorization with GitHub in the Bintray documentation.

Import a GitHub organization

You can import a GitHub organization while you create a new one in Bintray, or to an existing Bintray organization at any time.

Import GitHub organization to a new Bintray organization

When creating a new organization in Bintray you now see a new option to import your organization from GitHub:

Create new organization

If you choose ‘Import from GitHub’, your GitHub organizations, that have not been imported yet, will be displayed for you to choose from:

Select Organization to Import upon new organization creation

Once you make a selection, your GitHub organization is successfully imported to Bintray. Note that at this point, only the organization is imported, without members or repositories.

At this point Bintray offers you shortcuts to the most common options you naturally wish to do now:

Organization was created successfully

I will elaborate on how to sync members to your imported organization, and how to import an organization repositories later on in this post.

Import GitHub organization to an existing Bintray organization

To associate an existing Bintray organization with a GitHub organization, access the ‘Accounts’ section in your Bintray organization’s profile page. Bintray lets you choose from your accessible GitHub organizations:

Select organization to import to an existing organization

Sync members

Bintray Professional accounts can also sync members from a GitHub organization and have membership changes in a GitHub organization automatically synced to the equivalent Bintray organization. To sync members automatically, click on the ‘Sync’ button in the ‘Members’ section of the organization profile page:

Sync members

The sync will generate an invitation in each member’s Bintray mailbox. Once a user approves his membership, he becomes a fully synced member in the Bintray organization.

The following rules apply once your GitHub organization is imported:

  • All GitHub organization members will be members in the corresponding Bintray organization (as long as they are users of both).
  • GitHub teams are now teams in the corresponding Bintray organization.
  • Members’ permissions are also imported: an ‘owner’ in a GitHub organization will be an ‘admin’ in Bintray, a ‘member’ in GitHub stays a ‘member’ in Bintray.
  • Member’s privacy attributes, ‘private’ and ‘public’ in GitHub, are kept as ‘public’ and ‘nonpublic’ in Bintray .

You can keep the members list synced with Github, so any member added to or removed from GitHub in the future will automatically be updated in your Bintray organization. This saves you the worry of maintaining members in both Bintray and GitHub. You can also disable member sync, so that it is a onetime procedure. Members’ syncing can be enabled or disabled at any time.
For a step by step instructions of how to import GitHub organizations and members, please refer to the user manual.

Import a repository

At this point it makes sense to add a repository to your new organization. Importing GitHub organization repositories is now available! (previously, it was only possible to import personal repositories). In order to do so, create a new repository under your imported organization. In the repository page, click on ‘Import from GitHub’:

Repository page import from GitHub
Bintray will display all the GitHub repositories and their release tags under the imported organization:

Import GitHub repositories

Select the repositories and releases you wish to import, and remember that GitHub repositories will be Bintray packages, and GitHub release tags will be versions in Bintray. Note that the import includes the repository structure and not the actual files.

You can read more about importing GitHub repositories here.

If you use both GitHub and Bintray, this cool new feature will save you time and reduce hassle.
Good Luck!

Catch that Millionth Download with Bintray’s New Statistics API

Want to know exactly how many times your packages have been downloaded? Bintray has always given you download statistics through its UI, but now you can also get them for professional repositories via REST API. Detailed statistics on downloads per version over any time frame give you deep insights into how your software releases are consumed.
If you have never used statistics in Bintray, go ahead and check it out in the user guide.

Let’s see an example
Say I want to get the daily number of downloads of ‘myCoolPackage’ from October 1st to October 8th, 2015. This is what the stats look like in the Bintray UI:

myCoolPackage Downloads UI Stats Per Week

According to the chart, ‘myCoolPackage’ was downloaded a total of 147,752 times in that period. We can clearly see that there were downloads every day; there were dips on October 4th (Sunday) and October 8th (the chart was generated on October 8th around midday), and the most popular versions were 1.1.0 and 1.2.0.

Now you can get all this information programmatically using the new REST API. Here’s the “daily downloads” API as it is described in the REST API documentation:

GET /packages/:subject/:repo/:package/stats/time_range_downloads

To get the statistics displayed in the chart above, I would use the following command:

curl -X GET "https://api.bintray.com/packages/tamarUser/Maven/myCoolPackage/stats/time_range_downloads" -u tamarUser:***my-top-secret-api-key*** -H "content-type:application/json" -d “{\"from\":\"2015-10-01T12:08:56.235z\",\"to\":\"2015-10-08T12:08:56.235z\"}"

I get the following response in JSON format:

{
  "from":"2015-10-01T00:00:00.000Z",
  "to":"2015-10-08T23:59:59.999Z",
  "records":[
      {"date":"2015-10-01","downloads":
        [{"version":"1.0.5","count":1939},
         {"version":"1.1.0","count":6950},
         {"version":"1.1.3","count":293},
         {"version":"1.1.7","count":116},
         {"version":"1.2.0","count":10111},
         {"version":"1.2.1","count":1329},
         {"version":"1.2.2","count":1706}]},
      {"date":"2015-10-02","downloads":
        [{"version":"1.0.5","count":315},
         {"version":"1.1.0","count":6975},
         {"version":"1.1.3","count":198},
         {"version":"1.1.7","count":121},
         {"version":"1.2.0","count":9967},
         {"version":"1.2.1","count":1290},
         {"version":"1.2.2","count":1759}]},
      {"date":"2015-10-03","downloads":
      ...]
}

The response provides all of the same data that Bintray uses to create the chart in the UI. For each day within the requested date range in which downloads occurred, it lists the number of downloads per version. As simple JSON output, you can easily parse the response and use it any way that helps you analyze your package downloads quickly and effectively. You are now able to identify trends in downloads, your popular versions and more.

Other statistics REST APIs include: total downloads and downloads by country. Keep an eye on this blog to hear about new APIs when we add them.

Good luck!

Increase your Maven Package’s Exposure by Adding it to JCenter

If you already distribute your Maven packages via Bintray, your packages can gain further exposure by including them in Bintray’s JCenter! (if you are not very familiar with Bintray’s support for Maven, please refer to the user guide and to my previous post).

JCenter is the repository with the biggest collection of Maven artifacts in the world. And it’s on the best software distribution platform around – Bintray. This is where you want your Maven packages to be! CDN speed, user exposure, and live statistics to monitor the use of your artifacts are some of the benefits you get from JCenter. And if you really want to, you can also have your project synced with the older Maven Central repository.

Submit an Inclusion Request to JCenter

To promote sharing of packages within the developer community, once you have uploaded a package to one of your repositories, you can submit a request to the owner of any other repository to have your package included in theirs. If your request is granted, your package can be found just like any other package in that repository. You still maintain full control over the package in your own repository, and any changes you make to it, such as delivering new versions, or even removing it, are automatically synced to the other repository in which it’s included. So to maximize exposure of your Maven package in Bintray, all you need to do is request to have it added to JCenter.
In order to submit a request, just click on the ‘Add to JCenter’ button:

Add Package To JCenter
Once a Bintray moderator approves your request, your package will be available on JCenter, and you will receive a message into your Bintray mailbox. You will also see that your package is now linked to JCenter:
Maven Projects Linked To JCenter

Sync with Maven Central

At this point you can also have JCenter sync your package to Maven Central if you need to serve frameworks still using this repository. All you need to do is click on the ‘Maven Central’ link as shown above. Remember that you need to provide your Sonatype user name to Bintray before the syncing, but don’t worry, Bintray will remind you to do so if you haven’t already added it to your profile under Accounts:
Accounts Sonatype
Bintray takes care of the rest. Please also refer to the step by step instructions for how to sync your artifacts with Maven Central.

Good luck, and keep your package front and JCenter!

Publishing Your Maven Project to Bintray

Bintray gives you everything you need to share your Maven project, and much more: you will be able to monitor downloads and users with the statistics that Bintray keeps for you. You can also share your project via Bintray’s JCenter repository (which is the largest public Maven repository out there), and effortlessly sync it with Maven Central, if you wish.

Just follow these 5 simple steps to upload your Maven project to Bintray:

1. Have your Maven project ready

  • For this use case we will assume we have a maven project with the following groupId: org.jfrog.example.bintray.maven

2. Create a Maven package in Bintray

  • Open a Bintray account if you have not done so before.
  • Use the default Maven repository under your account or create a new one. The is where your Maven files will be hosted.

Create New Maven Repository

  • Under the Maven repository create a new package for your project. The package is merely a logical container that holds metadata about your project and annotates your files to allow Bintray to collect package and version level statistics.
    A good name for your package would be your main artifactId, but any name that logically identifies your project will do just as well.
    In our case, a good example would be: maven-example

3. Add the Bintray distribution URL

Next thing you need to do is to add a distribution section to your project’s pom.xml, and specify the URL from which to distribute your project. We will use our Bintray Maven repository and package as the target for deployment (remember? files in Bintray are always associated with a logical software package).

<distributionManagement>
  <repository>
      <id>bintray-repo-maven-example</id>
      <url>https://api.bintray.com/maven/tamarjfrog/maven-repo/maven-example/;publish=1</url>
  </repository>
</distributionManagement>

For your project to be visible to others, Bintray requires that you publish it. One way to do that is to add the publish directive to the distribution URL as a matrix parameter (;publish=1) as I did in the above example. You can also publish your projects at a later time using  the Bintray UI or via REST.

This block also includes an <id> tag. The id can be any string, but it should match the id in the settings.xml file described in the next step.

4. Provide your credentials to Bintray

In order to work with Bintray you need to provide your Bintray username and API Key as upload credentials in the username and password tags of your Maven settings.xml file. The API Key can be found when editing your Bintray profile page.

<server>
  <id>bintray-repo-maven-example</id>
  <username>tamarjfrog</username>
  <password>***my-top-secret-api-key***</password>
</server>

5. Time to deploy!

You are almost there. This is the time to run

mvn deploy

The project will be built, uploaded to the the Bintray repository target URL you provided, and published. You can now see your files in your Maven package in Bintray.

Maven Package Files List.
At this point, you can add your project to JCenter, the most comprehensive public Maven repository, so your project is well exposed. To read more about that, stay tuned for my next post.

A sample project similar to what I used in this post can be found in GitHub: bintray-examples/maven-examples.

Good Luck!

Creating a Signed URL Using the Bintray UI

Creating a Signed URL is now available to you through the Bintray friendly User Interface, from start to end.
If you are new to Signed URLs, you would rather check out this cool feature. Refer to the REST API Guide at URL Signing, and to the Sign me up! blog, discussing generating Signed URL using REST APIs.

Signed URLs are great for handing off a link to a single file download. They allow you to provide a link to download a published file from a private repository to a person that is not even a Bintray user! You are still able to track and monitor downloads volume and the identity of the users.

If you want to share a package or repository, or need to have more fine grained permissions control, take a look at Download Keys and Entitlements.

The scope here is files, hence, the option to generate a signed URL is available in the files view, under ‘Actions’:

Generate Signed URL

Once hitting ‘Generate signed URL’, the following form is opened:

Generate Signed URL Scrrenshot

This is where you wish to provide some extra parameters that make the Signed URL even smarter. All parameters are optional, except to the expiry field that is set to 30 minutes by default. The other parameters are described in the REST API guide.
The URL will be generated once you click ‘Create URL’. The file can be downloaded using curl in command line:

curl –X GET “signed URL” > filename.ext

Or just by copying and pasting the Signed URL into your browser.

Creating a Signed URL has never been easier!

Even more Vagrant love in Bintray

You, of course, know, that for nearly the last two years, you have been downloading your Vagrant software from JFrog Bintray. But recently, Bintray has taken Vagrant support to a whole new level; it is now is a fully fledged Vagrant repository allowing you to distribute your public and private Vagrant boxes from Bintray! As for everything in Bintray, it’s simple and powerful:

Publishing Vagrant Boxes

1. Create a Vagrant repository (if you’re a new user it is likely that you already have a default Vagrant repository named “boxes”):

Create a Vagrant repository

2. Click on “Set Me Up!” and copy/paste the REST command to upload the boxes:

Create a Vagrant repository

Consuming Vagrant Boxes

Follow the “Downloading” section under “Set Me Up!” to configure box resolution for downloading Vagrant boxes, and be able to enjoy automatic box update during ‘vagrant up’ a box either by an explicit call to  ‘vagrant box update’. That’s it, now you can benefit from all the power behind Bintray distribution: CDN, stats, logs, version notifications and more. So give it a try, put a box or two on JFrog Bintray today!

Enterprise Level Access Control with Keys and Entitlements

entitlements200x190

“Private repositories”, “Teams and Organizations”, “Permissions”…, sounds like that’s all you need to provide secure private downloads. Well, not quite. Those are great features that fit the bill if your consumer is a Bintray user. But what if she isn’t? Well, then there are signed URLs. Those should do the trick. Just sign your file and send your consumer the URL. But what if you want to share an entire repository, package or version with a group of people, but need to give each of them different privileges. Some can only view or download your files, but others should be able to delete your files or upload new ones. Signed URLs don’t cover that kind of control. They are great for single files, but for more fine-grained access control, you need a more sophisticated feature. That’s where entitlements and keys come in.

“Entitlements,” you said? What are those?

Entitlements are privileges you can give anyone…yes anyone, not only Bintray users, to entities in your private repositories. “Entities” means anything that can contain files – a whole repository, a path within the repository, a specific package or a specific version. “Privileges” means “rw”  – download, upload and delete, or “r” – download only. If you didn’t notice, the combination of entities and privileges gives you any level of granularity that you need for providing access.

But how do you unlock entitlements?

I guess you get the hint. Keys unlock entitlements. You generate a key along with its password (or Bintray can generate one for you automatically). Your user will have to provide the username and password to enable the key that unlocks the entitlement. That’s where the security lies. Only users who have both the username and the password of the key that you provide to them can access your repository entities according to the entitlements you created.

So how does it all work?

Two simple steps using Bintray’s REST API:

  1. Create keys. You can supply a password for each key you create, or Bintray can generate one for you.

  2. Create entitlements. When you create entitlements, you specify which keys to apply to them.

Now all you need to do is provide your user with the username and password for one of those keys. Your user now applies a REST API to access your private Bintray resource while including the key and password you provided as parameters to the API call. Bintray will check if there is an entitlement that allows access to that resource, and if that entitlement has the key that the user specified associated with it.

Let’s see an example at work

Let’s say user “ACMECorp” has a private repository called “acme”.

This private repo contains several versions of acprod under the “acmecorprod” directory that are protected from public access.

ACMECorp wants to authorize a “platinum customer” to download the different versions. Needless to say, “Ms. Platinum” does not have a Bintray account.

First, ACMECorp needs to create a key. Bintray offers two ways to maintain control over keys that are distributed to outside users. The easy way is to just put an expiry date on the key. A more advanced method is to set up an internal server that is used to validate and authenticate keys, and provide the server URL to Bintray when a key is created. Every time a user tries to access ACMECorp’s repositories, Bintray will validate the key using  the URL that ACMECorp provided when creating it. Since ACMECorp is very careful with its key, let’s assume they want to validate keys with their own systems:

curl -XPOST -uacmecorp:APIKEY “https://api.bintray.com/users/acmecorp/download_keys
{
“id”: “key1″,
“expiry”: 7956915742000
“existence_check”:{
      “url”: “http://callbacks.myci.org/username=:username,password=:password”,
      “cache_for_secs”: 60
      }
}

Bintray creates a key and its associated password

Status: 201 Created
{
"username": "key1@acmecorp",
"password": "8fdf84d2a814783f0fc2ce869b5e7f6ce9f286a0"
}

ACMECorp now creates an entitlement that provides download privileges to the acmecorprod directory, while assigning key1 that was just created

curl -XPOST -uacmecorp:APIKEY "https://api.bintray.com/packages/acmecorp/acme/acprod/entitlements
{
"access": "r",
"download_keys": ["key1"]
}

Bintray responds:

Status: 201 Created
{
"id": "7f8d57b16c1046e38062ea3db91838ff77758eca",
"access": "r",
"download_keys": ["key1"]
}

Basically, that’s it. ACMECorp can now just provide the username “key1@acmecorp” and its password to Ms. Platinum who can now use them to access the acmecorprod directory in ACMECorp’s repository.

For example, to download version 1.0 of acprod, Ms. Platinum would use:

curl -XGET “https://dl.bintray.com/acmecorp/acme/acmecorprod/1.0/acprod.exe” -ukey1@acmecorp -p”8fdf84d2a814783f0fc2ce869b5e7f6ce9f286a0”

But what happens now if ACMECorp and Ms. Platinum have a falling out. When that happens, ACMECorp can just delete the download key from their validation server and “Hey presto”, Ms. Platinum is now locked out of ACMECorp’s repositories.

Try doing that on Docker Hub, RubyGems.org, NuGet Gallery, Maven Central or any other repository or download center out there. Bintray is the only one that provides you with this level of control over access to your private resources.

Is Docker Hub really the best way to distribute your images?

Docker is definitely one of the biggest things to hit the software industry in the last few years. Everyone is using Docker, and Docker Hub is growing rapidly serving over 45,000 images by now. But did you ever ask yourself if Docker Hub is really the best platform to distribute your Docker images. It stands to reason, but reason be damned; We think Bintray has an edge over Docker Hub and here are the reasons why.

1. Fine-grained access control

Yes, Docker Hub recognizes organizations and teams. You can have all the relevant people open an account on Docker Hub and then organize them in whatever way serves your needs to expose or hide registries as you see fit.

But then you want to send your #1 strategic client an early release

How does Docker Hub handle that? Well, you can ask for your customer’s account, and then include him in the right organization or team. But then, you need to be really careful with what you put in the repository you have exposed to him. Or you need to add him to a team, and later remove him. Manageable so far… But now he also wants his boss to see it, and later the CTO, and two weeks later, you find that your guy has just changed jobs and is working for your competitor. Did you remember to remove him from that team or can he still access your private repository?

Bintray removes this pain-point with entitlements and download keys

Bintray lets you create entitlements which define, in minute detail, exactly what part of a repository can be accessed – from a whole repository down to the level of a single path within a repository. You can define who has access by name, geographic region, IP domain and pretty much anything else. You can also limit that access to a very specific period of time. Once you have defined your entitlements, you can then create keys which unlock the access the entitlements provide. Your user needs to provide the key and its associated password each time he accesses a resource which he is entitled to. You can even define what kind of access each entitlement provides. It can be for download only, or for download, upload and delete.

2. Image and Version Level Stats and Logs

Ever wondered how many times your image has been downloaded? Of course you have; it’s a measure of success. But going beyond self-flattery, it’s not enough to know that magic number of downloads. Wouldn’t it be helpful to be able to know who downloaded your images and from where? Bintray gives you that. The stats pages on Bintray give you total numbers, but download logs let you segment the downloads by region, country, IP address, and even down to the specific user and organization. For your public repositories this can be really useful, but for your private repositories it’s critical for you to know who is accessing your packages and what they are doing in your repositories. You can read more about stats and logs in this post the Bintray Blog.

3. There is more to the world than Docker

allforone4Docker may be the best container to have ever hit the software docks, but at the end of the day, you are only using Docker to create a virtual world in which to run your products. And your products are built with packages that are Java, Ruby, NuGet, Python, Debian … and new formats hit the news all the time. How are you going to distribute those? Not on Docker Hub. So should you use Docker Hub for Docker and something else for all the rest? Well, if you can use that something else, aka Bintray, for Docker images too, then why not simplify your life (and scripts) and distribute all packages through Bintray.

All for one and one download center for all.

3.5. For Bintray, distribution is a core competency

Docker is making huge waves in container technology. This is their core competency; not software distribution. You can use Docker Hub to distribute your images, but you must ask yourself, “Will Docker Hub receive the same level of attention from its makers as container technology does?” Bintray’s scalable infrastructure is deployed on clustered servers in multiple data centers around the world, and currently serves over 200 million downloads per month of 200 thousand packages that reside in 50 thousand repositories.

That’s what we call a core competency!

Like Docker Hub, Bintray offers a host of great features like fast CDN downloads, a rich REST API for automation, searchable metadata and more. But like Docker is redefining container technology, Bintray is redefining software distribution. The service tiers offered by Bintray make it the best choice for distribution of both free OSS images as well as for commercial organizations that need enterprise grade software distribution features. Bintray lives and breathes software distribution; that’s what it does, and that’s where it will continue to evolve to stay the best solution for a download center, for Docker images and indeed for all other software package formats.