What is Tyk On-Premises / Self-Managed ?
Tyk Self-Managed is the way to install our Full Lifecycle API Management solution in your own infrastructure. There is no calling home, and there are no usage limits. You have full control.
Installing Tyk Self-Managed:
Please visit our Self-Managed installation page to get started.
Read more about licensing here.
The full Tyk Self-Managed system consists of:
- Tyk Gateway: The API Gateway that proxies and manages your traffic.
- Tyk Dashboard: The management Dashboard and integration API for managing a cluster of Tyk Gateways, also shows analytics and features the Developer portal.
- Tyk Pump: Handles moving analytics data between your gateways and your Dashboard (amongst other data sinks).
- Tyk Identity Broker (Optional): Handles integrations with third-party IDP’s.
- Tyk Multi-Data Center Bridge (Optional, add-on): Allows for the configuration of a Tyk ecosystem that spans many data centers and clouds.
Dependencies & Database Support
By default the Tyk Dashboard uses MongoDB. You can use the following as a drop-in replacement:
- MongoDB 3.x and 4.0.x
- MongoDB Cloud / AtlasDB
In order to integrate with AtlasDB, make sure the IP firewall connections are whitelisted on the Atlas side, and then use the following Tyk Dashboard configurations to connect:
- TYK_DB_MONGOURL=mongodb://admin:[email protected]:27017,tykdb-shard-00-01.h42pp.mongodb.net:27017,tykdb-shard-00-02.h42pp.mongodb.net:27017/tyk_analytics?authSource=admin - TYK_DB_ENABLECLUSTER=false - TYK_DB_MONGOUSESSL=true
More information on these configuration variables here.
Visit the Gateway page for more info.
- Redis 2.8.x to 5.0.x
- CentOS 6, RHEL 6, Amazon Linux ship with Upstart 0.6.x
- Ubuntu 14.04, Debian Jessie with Upstart 1.x
- CentOS 7, RHEL 7, Ubuntu 16.04, Debian Stretch are running with systemd
- Certain older distros may only provide SysVinit but all of them typically provide compatibility with its scripts
Note that any init scripts of your choosing can be used instead of automatically detected ones by copying them from the
install/inits directory inside the package directory.
This init system variance implies there are different ways to manage the services and collect service logs.
For Upstart, service management can be performed through the
initctl or a set of
status commands. Upstart 1.x also works with the
For systemd, either
service commands may be utilised.
service command can usually be used with SysVinit scripts, as well as invoking them directly.
Service logs availability
- Upstart 0.6.x and SysVinit: log files are located in
/var/logsfor every respective service, e.g.
- Upstart 1.x: by default everything is stored in
- systemd utilises its own logging mechanism called journald, which is usable via the
journalctl -u tyk-gateway
Please consult with respective init system documentation for more details on how to use and configure it.