Category: Tyk API Gateway

Tyk 2.2 is Here!

That’s right, the long awaited version 2.2 release is finally here, we’ve been cleaning up, adding features and most importantly, making Tyk easier to use.

The Gateway

Now features some pretty cool new features:

  • OAuth now has support for the client credentials flow
  • It is now possible to use generative security policies with OAuth clients, that means no more needing to send any session data back to Tyk!
  • XML support for inbound and outbound body transforms
  • Context Variables: Get quick and easy access to request data across a variety of middleware, data such as requester IP, form data, headers, path parts and other meta data, all available to the transform middleware
  • Partitioned Policies: Now you can have policies only affect one part of a token instead of all elements, for those who have very complex sales strategies or quota allocation strategies, this makes it much easier to manage. So instead of having to grant ACL, Quota and Rate Limit rules in one go, you can just grant ACL rules, or Quota rules, or both.
  • Normalised URLs in analytics: With this latest update you can normalise the URLs in your analytics to remove those pesky UUIDs and Numeric IDs for more meaningful data


We’ve left this for last, because we’re pretty happy about this, Tyk now transparently supports Websocket proxying as part of your APIs, and these can be protected by the same mechanisms that currently protect your existing APIs, be that Bearer tokens, our Circuit Breaker, or our Load Balancer, the websocket proxy is transparent and will “just work”.

The Dashboard

The dashboard now has a UI for all of the above features, but the biggest change you will find is our new i18n support. That’s right, Tyk Dashboard now has language-pack capability.

To get things started up, we’ve translated the UI into Simplified Chinese and Korean, and have made the language packs available as an open source repository here.

That’s right, it means that it is easy and dynamic to add a new language to Tyk (or to change the wording of the UI if it doesn’t suit you). All of this is configurable and easy to deploy, so have at it.

This update has been a small one for us, because we’re trying to make smaller, more effective releases that help our community and users instead of breaking things. We’ve got some pretty major features in the pipeline coming up, but our real focus will be on stabilising the platform.

As always, Tyk is available on our apt, yum and docker repositories!


Martin & The Tyk Team.

Tyk v2.1 is out – Now with Open ID Connect, bug fixes and more!

Recently we announced that we had added full support for Open ID Connect to our Cloud platform, and that we were moving it to our next release in due course.

Well, the wait is over – and as of today it is available to everyone! That’s right, Tyk v2.1 and Tyk Dashboard v1.1 are now available.

This release’s main feature is the OIDC support, however we have also made many improvements and bug fixes, all of which can be seen in the Change Log.

To get started with 2.1 you can just upgrade your existing installations, all the deployment methods are supported and v2.1 will be the default installation for all major distribution methods, but before you go off and do that, please back-up your configuration files!

This is our first attempt at making smaller, more regular releases to ensure that upgrades are easier and involve less risk for you, we dog-food every feature and change in our cloud platform before we cut a version for on-premise installation, so you can be sure that we’ve put all our builds through their paces.


Martin & The Tyk Team

Integrating Tyk Open Source API Gateway with a Custom Identity Provider using JSON Web Tokens

That’s quite a mouthful. But hey, you know what a lot of users want to do? Use their own Identity Provider, and the new hotness is JSON Web Tokens. For those who don’t know what they are, they’re pretty friggin’ cool – find out all about ’em here. We’re going to use them to do some cool trickery/magicky API Gateway token gen without even having to generate a token


But seriously, it’s pretty cool – in short: you can have a custom Identity Provider (IDP) generate JSON Web Tokens for you, and then use those tokens directly with Tyk, instantly – better yet, the underlying identity of the token (it’s owner) is tracked across JWTs, that means they can log in elsewhere, or via a different app or portal and still get the same rate limits provided (or different ones, it’s all up to your IDP, not us!).

So how does Tyk Magically do this? Well, the process is pretty involved, so we thought we’d talk you through it:

Centralised secrets and virtual tokens

With centralised secrets, we do not create any tokens at all within Tyk, instead all tokens are generated externally. Centralised secrets involves storing a shared secret (HMAC or RSA) at the API Definition level, this secret is then used to validate all inbound requests, and applies access rules based on specific fields that can be added to the claims section of the JWT to manage the underlying identity’s access to managed APIs.

To use this option, we do not generate a token at all, instead we go to the API Designer, and under the JWT Shared secret section (when selecting the JWT security handler), we add the shared secret (recommended is a public key)

First, let’s set things up:

  1. In the API Designer, we select “JSON web Token” as the authentication mode
  2. Select RSA as the signing method
  3. Add a secret (public key)
  4. Set identity source to be “sub” – this tells tyk which claim in the JWT to use as the base “identity” of the JWT, i.e. the bearer (this might be a username, or an email address, or even a user ID), a common JWT claim is “email”, we could use that too
  5. Set the policy field name to be “policy” – this tells tyk which claim in the JWT to use to identify the policy to apply to this identity, as in: the access control, quota and rate limiting settings to apply to this identity
  6. Save this thing, it will now go live onto your gateway

Now lets create an actual policy:

  1. In our Policies section, we create a new policy called “JWT Test”
  2. Set the quota and rate limit rules, most importantly, we grant access to the API we just created

Let’s say when we save this policy, the ID returned is 1234567

So, let’s walk through a user flow:

  1. A user goes to a third-party login portal and authenticates themselves
  2. This third-party system generates a JWT using it’s private key, and in this JWT adds the following claims:
    • policy: 1234567
    • sub: the user’s email address
  3. The user is then granted this JWT (maybe as a fragment in the URL) and uses it to access the API we created earlier
  4. Access is magically granted!

Tyk will now validate this request as follows:

  1. It extracts the JWT from the request and validates it against the stored JWT that we added at the API level in step 1.2
  2. If the token is valid, it looks for the identity source field, since this is configured as “sub”, it finds the user’s email address
  3. It uses the email address to generate a hash of the address, and then creates a new value of {org-id}{hash(sub)} – basically it generates an internal token that is bound to the identity (it will be regenerated each time this sub shows up)
  4. Tyk extracts the policy ID from the claims and retrieves this from memory (if it exists)
  5. Tyk now tries to find this internal token hash in it’s key store – if it exists, it applies the policy to the key (this does not override existing values, it just sets the maximums so that they have an immediate effect if changed), access control rules are overridden too, so they can be changed depending on the access source or IDP doing the logging in
  6. If the internal token does not exist, Tyk creates the token based on the policy data – same as earlier but with a new identity-based token
  7. When the token is created, the internal token ID is added to the metadata of the session as a new field: TykJWTSessionID (This is important, because now you can reference this meta data object in the transforms middleware, for example, you could inject it as a custom header into the outbound request, so your upstream application has access to the original JWT and the internal Tyk Session token in case it needs to invalidate or track a specific user’s behaviour – aren’t we gosh darn helpful). Now since these session IDs do not change, they exist across JWT’s for this identity
  8. This internal token is now used to represent the request throughout the Tyk request chain – so now the access control, rate limiting and quota middleware will act on this token as if it were a real key – but it leaves the actual JWT intact in the request so it can be processed upstream
  9. If the access rules set by the policy referenced in the JWT’s policy field are all valid, the request is allowed to pass through upstream

Phew! That’s a lot of steps, but it means that you can handle access control in your IDP with a single added claim.

Anyway, we thought it was interesting – we hope you did too!

Simpler usage tracking with Token Aliases in Tyk Cloud!

So you might have noticed that this week we needed to do a little tinkering with our servers – thanks for your patience while we sorted all that out. We’re growing so quickly that we’re constantly pushing new features. One that went out today that we’re particularly happy with is Token Aliases.

What the heck is token Alias?

As you might know, Tyk will hash all keys when they get created so that they are obfuscated should your DB be breached, this creates a unique problem – how do you identify the tokens in your logs? That’s what Aliases aim to solve.

An Alias can be set on any token, and when the token access your APIs, the alias will be stored alongside the token ID in your analytics and displayed in your dashboard.

What’s more, when a developer generates a token via your API Developer portal, Tyk will auto-assign their email address as the alias to their token so that you can track their activity more easily.

(P.S. If you’re an on-prem user, this feature will be available in the nightlies tomorrow!)

Really simple, and really useful – enjoy Tykers!

Tyk Nightlies for Nighthawks

The Tyk Open Source API Gateway platform consists of quite a few modules: The Tyk Open Source API Gateway, the Tyk API Management Dashboard, Tyk API Analytics Pump, Tyk Identity Broker and more.

For those more adventurous types out there that have grabbed our open source API Gateway repository and compiled Tyk yourselves, you’ve been some of the few that have had access to the latest and greatest features. However, even you brave souls still miss out on getting all those awesome features delivered to your API Dashboard, waiting on us schlubs to release a new version so you can get all the juicy API Management goodness.

Well, the wait is over! We’re really quite happy to introduce the Tyk Nightly builds, which – basically – are what they say on the tin. We now build the development branch of Tyk, Tyk Dashboard and Tyk Pump every night, and deposit them in our file repository in AWS S3 for you to download and enjoy.

Now it goes without saying that these builds are not guaranteed and that using them puts you in danger of being eaten by a swarm of flying zombie sparrow-hawks, but for those truly brave, and truly wishing for the latest and greatest in open source API Gateway goodness, this is for you.

The files (are all here)[/docs/tyk-api-gateway-v-2-0/installation-options-setup/nightly-builds/] – go nuts.

Tyk’s Big Sister Has Landed: Tyk 2.0

It’s spring, spring is the season of new life, new beginnings, birth.

Well, we’ve been busy little midwives, and Tyk 2.0, Tyk’s big-ass big-sister, is here. She arrived sowing a trail of highly-organised, efficient and carefully designed API gospel, swarmed by the cluster of little Tyk* in her wake, parked in front of the brand-spanking new Tyk Towers in London and promptly sat on the dog.

The dog is now smaller, but happy.

That’s right, We’re back with a spring clean of the site and a brand new version of Tyk.

Some new names

Names are important, and we want to remove confusion from Tyk, so we’ve made some changes to reflect the different elements of the Tyk ecosystem.

Tyk API Gateway is now Tyk Community Edition: our community has been growing rapidly since we opened our new forum, and we’ve been getting increasing interest, pull requests and contributions from a wide segment of the Tyk developer community – a big fat thank you for that, it’s the Tyk community that makes it what it is, and makes it so damned awesome. So we named Tyk after you, since you’re the ones that drive it.

Now, if you’re a Tyk Cloud user, then you’ll already have seen some of the 2.0 features crop up in your UI, since we’ve been running v2.0 on Cloud for some months now.

New features

So, brass-tax, what’s new, “what the heck have you made us wait for all these months”, we hear you say… well, the highlights for Tyk Community Edition:

  • Major performance improvements
  • GeoIP Analytics
  • Detail logging: Log requests and response data for easy tracing, this can be done dynamically using an ORG key for easy debugging
  • Full JWT support: the best way to integrate with other service providers
  • Completely rewritten HMAC support, now fully compatible with the latest spec
  • Multi-target support for versioned APIs
  • Improved stability & failure handling
  • Improved logging for better traceability
  • New, pluggable data sinks with Tyk Pump:
    • MongoDB
    • CSV
    • ElastiCache
  • Third party IDM support for LDAP, Social, Basic Auth & Proxy
  • Mesosphere support for service discovery

Of course there’s loads more over in the changelog.

Tyk Professional Edition

And what about the dashboard? Well, the dashboard is now Tyk Professional Edition, there is still a free edition, but it now has a paid for license option for larger deployments too. With Tyk 2.0, we bring Dashboard 1.0, which has some important and amazing new features:

  • New analytics views on a per API, per country, per tag basis with drill-down
  • New Geographic traffic charting – see where your developers and users are
  • New detailed log traces for debugging APIs
  • Realtime notifications of key team and cluster actions
  • IDM Integration management from the dashboard
  • Node status overview: what’s up, what’s down
  • Aggregate developer usage data in profiles
  • Granular user permissions & API client permissions for integrations
  • Faster DB and analytics access throughout
  • Improved analytics speed and caching
  • Improved Open API definition support in the portal
  • Better, more usable UI

Wait a sec, Tyk Dashboard can cost money?

Tyk Pro is still free for single node deployments (managing a single Tyk API Gateway from the Dashboard), but for anything larger, there is a license fee attached.

Tyk Pro not only gives you the dashboard, but each paid license also includes our Premium Support package, so a license purchase also gets you one-to-one engineering support right from the get-go.

For existing users, we are not removing old versions of Tyk Dashboard, those will still be available for download and installation – and the documentation is still available on this site, but they will not work with the latest version of the gateway.

Tyk for Enterprise

We weren’t kidding when we said we’ve been busy, and that Tyk 2.0 is a big-momma-bear API Management platform. For Enterprise users, we’ve been busy doing PoC’s, signing SLA’s and consulting with big giganto-corps, and we’ve been busy taking notes, studying and learning, and in response, Tyk for Enterprise is a new beast.

Tyk for Enterprise not only offers our incredible SLA’s, but also comes with our new multi-data-center bridge component, enabling large enterprises to run isolated, zoned Tyk Clusters that are managed centrally, with a clear, easy way to move APIs between environments, between clusters, between zones, and between geographic locations. We call it the Tyk Multi Data Center Bridge, it powers Tyk Cloud Hybrid, and it’s awesome.

Someone won the friggin’ Apple Watch

Some of you might have remembered our survey where we asked what you wanted, and we’ve been listening, we got some amazing feedback, and we’ve used it to drive our offering for large and smaller clients and much of it has gone into this latest, biggest, baddest, release.

The winner of the prize-draw for the watch was Diego Guario of Milan, Italy. We’ve never met Diego, but we know that he uses Tyk, which means he must be a smart, suave and sophisticated type of guy. Congratulations Diego!

So, to round things off – go forth, try Tyk Community Edition, get yourselves a Free Tyk Pro license, get involved, get busy, go get your Tyk on!

— Your’s truly,

Martin & the team at Tyk Towers

Image Credit: F4LL3N-0N3

Creating an IP-based rate-limiter with Tyk and JavaScript middleware

We’ve recently had a user ask if it was possible to have Tyk act as a rate limiter based on IP address instead of by token, this isn’t possible out of the box, but it is with our Middleware API and some simple JS So, you may ask yourself how we achieve this feat?

It’s actually really straightforward. First off, we’ll need to set up our API in a very specific way, we’ll use a file-based definition here as we’re assuming this is a simple deployment of Tyk. The way we will do this is by creating a custom JS middleware function that will run before any other Tyk processing takes place, this includes all rate limiting. The middleware will:

  1. Catch the request
  2. Extract the IP address from the header
  3. Create a key based on the IP address with a specific rate limit
  4. Inject the IP address as the authorization header for Tyk to use

This means that rate limits are on a per-IP basis, which is great, and also means that Tyk can just work through the request normally once the middleware processing is done.

We will start off by defining our API appropriately, we basically want an API that will invoke the middleware as a pre-processor, and then also ensure that any keys that are created do not last forever. The Tyk API Definition will look something like this:

    "name": "Tyk Test API",
    "slug": "test-name",
    "api_id": "ip-ratelimit-api",
    "org_id": "1",
    "use_keyless": false,
    "use_oauth2": false,
    "auth": {
        "auth_header_name": "x-tyk-authorization"
    "definition": {
        "location": "header",
        "key": "version"
    "version_data": {
        not_versioned: true,
        versions: {
            "Default": {
                "name": "Default",
                "expires": "3011-02-02 00:00",
                "use_extended_paths": true,
                "extended_paths": {}
    "proxy": {
        "listen_path": "/b605a6f03cc14f8b74665452c263bf19/",
        "target_url": "",
        "strip_listen_path": true
    "custom_middleware": {
        "pre": [
                "name": "ipRateLimiter",
                "path": "middleware/ipRateLimiter.js",
                "require_session": false
    "session_lifetime": 172800,
    "active": true

The key things of note here are the `custom_middleware` section, here we’ve defined where to find our files and what the objects are called. Next up is the `session_lifetime` value, this sets a default key lifetime for every key created on this API, in this case we’ve set it to 48 hours. Now that we are ready with the actual API, we can set up the middleware, it’s actually quite short – this is the entire IP rate limiter:

    // ---- A Middleware based IP Rate limiter -----
var ipRateLimiter = new TykJS.TykMiddleware.NewMiddleware({});

ipRateLimiter.NewProcessRequest(function(request) {
    // Get the IP address
    var thisIP = request.Headers["X-Real-Ip"][0];

    // Set auth header
    request.SetHeaders["x-tyk-authorization"] = thisIP;

    var keyDetails = {
        "allowance": 100,
        "rate": 100,
        "per": 1,
        "expires": 0,
        "quota_max": 100,
        "quota_renews": 1406121006,
        "quota_remaining": 100,
        "quota_renewal_rate": 60,
        "access_rights": {
            "ip-ratelimit-api": {
                "api_name": "Test API",
                "api_id": "ip-ratelimit-api",
                "versions": [
        "org_id": "53ac07777cbb8c2d53000002"

    TykSetKeyData(thisIP, JSON.stringify(keyDetails), 1)

    return ipRateLimiter.ReturnData(request);

// Ensure init with a post-declaration log message
log("IP rate limiter JS initialised");

The above code should go into a file called `ipRateLimiter.js` in the `middleware/` folder of your Tyk installation. If you start Tyk now, the IP rate limiter will be in place.

What is actually going on here? It’s exactly as we said above, we extract the IP address, here we are assuming that `”X-Real-Ip”` is a real header, since we are using NGinX to manage our domain, we have set a rule in the server block to make sure that the IP address is included as a header on each request:

location / {
    rewrite /(.*) /b605a6f03cc14f8b74665452c263bf19/$1 break;

    proxy_pass_header Server;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Scheme $scheme;
    proxy_pass http://tyk;

The thing of note here is `proxy_set_header X-Real-IP $remote_addr;`, this is important, as otherwise you won’t have access tot he IP address from the header. Once we have the IP address, we set this as the authorisation header for the request.

In the next section we have a template for a session object, here we are setting the rate limits manually, we could also use a policy file to do this and just attach the policy ID.

In this case we have set the rate limit to 100 requests per second with an overall quota of 100 per minute. We now use the built-in method `TykSetKeyData` to create the key, notice the last input to this function is `1`, this forces Tyk to not reset the quota for this transaction, which is the default behaviour – we don’t want Tyk re-setting the quotas and rate limiters every time the IP shows up, we just want to ensure the key is present.

When the middleware completes, Tyk processes the now-modified request as if it had an authorisation token (in this case the IP address) and the rate limits are enforced. And that’s it, this key will last for 48 hours, at which point it will be re-created. This means that your Redis instance won’t get flooded with infinite IP addresses as traffic grows. Enjoy!

Tyk 1.9 – Know more, be better

blog_tyk_1.9 I don’t know about you, but it feels like it’s been an age since we last got a release out the door. And we’ve been hard at work… making things, mysterious things. This year, for the holiday season, Tyk presents the glorious version 1.9 of our API Gateway and Management platform – a thunderous step forward in our mission to make the Internet a more connected place.

Or, better yet, why don’t I just tell you what we’ve been up to and skip the rhetoric?

This time round, we’ve concentrated on two things: 1. Making Tyk easier to install, manage, run and generally behave and 2. Making Tyk more aware (not Skynet aware… but that’s coming in v2.0, watch this space).

For those who can’t even, here’s the TL;DR version:

Tyk v1.9 now supports active uptime testing and polling of your service endpoints. Tyk will record uptime analytics for you including: average latency, errors, error type and success rates The host manager is no longer required, domain management is completely internalised in both the gateway and the dashboard We now have our own GPG-signed YUM and APT repositories and have secure deployment models for Ubuntu and RHEL Init scripts and configuration scripts are now included out of the box to make setup and configuration easier than ever A UX and design overhaul of the dashboard with plenty of bug fixes Now… for the meat…

Uptime Awareness I’ll start with awareness, v1.9 has something we’re labeling “Uptime Awareness”, we know many development teams have monitoring software that will check infrastructure, services and system health over time and wake some poor sod in the middle of the night with a blaring klaxon telling them that something is horribly, disastrously wrong, and in their bleary eyed confusion, rushing to their laptop, barely able to make out screen or sense, let alone remember their login details, they need to fix whatever just FUBAR’ed.

Which is great, in fact, it’s wonderful. Us dark-loving, vampire-like developers love being up in the middle of the night to fix stuff.

Or… not.

So that’s where we came along and thought, you know what an API gateway should do? It should try to detect downtime, and immediately react to fix it, without needing to get anyone out of bed. That, in fact, was the basis of us adding our Circuit breaker functionality in the last version – self-reliance..

Now I don’t want to over-simplify the awesome monitoring tools that exist today, you can use them to react to downtime and handle new instances / repairs and rollbacks through scripting, automated intervention and complex interactions, and they are far more feature rich than what Tyk offers. So to be clear, we are by no means trying to replace that.

Tyk’s new uptime awareness is designed to enable you, the API owner, to write a bunch of test requests that will be polled at regular intervals by your gateway, and should downtime occur in one of those over a set sample rate and interval, Tyk can pull that host out of its load-balancer host list until it comes back up again. And in an ideal world, never exposing the downtime to the end users for any significant period.

But, if you insist, or are a particularly cruel team lead, Tyk can also wake up your SysOps and DevOps teams if you like, we’ll send round some heavies to bust the door down and drag them out of bed by the hair… screaming. Ok, we won’t do that, but we can send event notifications to your monitoring services to set off a chain reaction that could, potentially, send some heavies round (you’ve been warned, devs!).

But for us, it’s all integrated. We wanted Tyk to be able to be reactive to downtime at the edge of the knife where it counts.

So, that’s what we mean by increased awareness – naturally Tyk will collect analytics on your behalf for each of your API, version, and individual tests, storing average latency, error codes and success rates so you can get a retrospective look at how your APIs are doing.

Did we mention that this all integrates with tools like Etcd and Consul? Yeah – you can configure uptime awareness dynamically using service discovery tools if that’s how you roll.

Deployment, stability, performance etc. The second big focus for us with this release is wanting Tyk to be “Well Behaved™”. Many of us who deploy software, release to servers or have to talk to the poor souls that manage releases every day, know that having a familiar deployment and installation pattern, and expected runtime behaviors to get things up and running is pretty great (and a relief).

Having to deploy some awkward tarball and fiddle with directories and configuration files and symlinks sucks.

So we got our sh*t together and did something about it.

What did we do?

The Host Manager is dead! Long live Integrated Domain Management!

We listened, and one of your biggest sources of confusion was Tyk’s reliance on NginX to map to domains and have an easy to understand domain/route architecture… well no more! We took the host manager out back, thanked it for it’s service, and kneecapped it.

So the Host Manager, while it will still work and continues to be supported (and a valued member of the team), is no longer strictly required.

That means two less dependencies for Tyk, which is great from a “moving parts” perspective, while also making it really easy to set up and manage domain-based access and routing for your APIs using whatever structure you want for your dashboard, APIs and Developer Portal.

Dedicated, GPG-signed APT and YUM repositories and packages

When you install Tyk v1.9, you will most likely be doing it via our shiny new installation method.

First off, we have both YUM and APT repos, and those repositories are GPG signed, and secondly, if you are a RHEL user, the RPM binaries themselves are signed too. So you can be sure that the package you are installing comes from, and is approved by, us – and we deliver it on a silver platter across the chain-link, barbed-wire laden fence that is a secure HTTPS channel.

Secondly, because the installations follow standard Linux patterns (in fact, they are the same patterns you would use to install any more standard bit of Linux software), it makes it easy and straightforward to work with, or modify existing configurations for Puppet, Chef, SaltStack or other configuration management tools to get Tyk installed on your hosts.

We’ve run these installations on AWS EC2 Ubuntu LTS and RHEL 7, and they should work on any cloud-based linux host.

Our new repositories currently have packages for:

Debian Jessie Ubuntu 12.04 LTS Ubuntu 14.04 LTS Enterprise Linux 6 Enterprise Linux 7 On ARM, i386 and amd64 architectures.

Naturally, we still have our Docker containers, and we’ve modified them now to be completely independent and make less assumptions about how they will be launched. This makes them much more modular and much easier to integrate with a microservices stack.

Upstart, SysV, Systemd init scripts

Finally, sane init scripts! (Be still my beating hearts)…

You can now start both Tyk Gateway and Tyk Dashboard with standard init commands – this is great from a testing and management perspective as you can now start your host services the same way as you would nginx or Redis, as a server task, that behaves itself, that does what it says on the tin.

This might not sound like much, or be particularly “fun” or value added, but as a piece of server software it’s important for us that Tyk can be installed, and run in a standard and familiar way, supporting whatever init system our developers prefer. For those tired-eyed SysOps that need to install stuff, lets make their lives a little easier.

Bootstrap and helper scripts

Configuring Tyk is not hard, but there’s a few simple things that can trip up some users, and there’s two clear modes that people want to run Tyk in – File based or Dashboard based. So why should we make it hard for you to get up and running? What gives us the right to make your life difficult? Exactly, we don’t, so here you go.

Because of this, we’ve created some bootstrap / configuration scripts that can be used to generate configuration files that are ready to go for either mode, without the need to fiddle or tweak them in any way.

Bug fixes and UX One thing you may notice, is that we’ve overhauled the dashboard look and feel, and fixed a few outstanding bugs that have been annoying our users – you can see the full fix list in the change log. But lets just say that things are a tighter, better put together, easier to use and more reliable than ever before.

Any questions, bribes or threats please address them to us on our GitHub page, or our Community forum.


Martin & the Tyk team

It’s alive! Tyk Cloud in open beta

Announcing Tyk Cloud

It’s happened, finally.

Today we’re happy to announce that Tyk is growing up, and that we’ve launched a cloud-based version of it.

Tyk Cloud is all the best bits of tyk, managed and deployed and supported by us. It’s free to use and is a great way for new users to get started with API Management.

What will happen to the open source version?

That’s the beauty of this – we are offering a hosted version of Tyk, it only has minor differences, and major changes and new features are pushed to the open source and freely downloadable versions of the product – development will not stop.

It will accelerate though.

A cloud platform means users can get up and running quickly, can trial Tyk without needing an install, or manage their own Redis cluster or MongoDB back-end, we take care of all of that. We’ve also made sure that our usage tiers are fair, easily accessible and do not have eye-watering prices.

It’s a pretty big change, for those that have followed Tyk since our initial version, you’ll know that we went from an open sourced / licensed model, to a support based but free model quite quickly, the change from closed to free really helped us get traction, and most importantly, build a community. Moving Tyk to the cloud is a natural evolution for the project, and a great technical showcase of what it can do.

Tyk Cloud is entirely built using the Tyk REST API and the Tyk Advanced Management API, so as a proof of concept and as a test-bed it is an excellent way for us to innovate and continue to evolve the product for our community.

If you’d like an invite code, there’s a lovely little form here to apply – I hope you are too 🙂

Cheers, Martin

Scroll to top