Menu

Frequently Asked Questions

General

Questions about the product and use cases

What is Pactflow?


At its core, Pact is a managed version of the Open Source Pact Broker, with added features for teams and enterprises looking to scale their contract testing.

Pactflow allows teams to increase their application quality and time-to-market by speeding up the release cycle for large-scale integrated systems. Whether you build microservices, messaging systems or cloud native (e.g. lambdas) systems, Developers and Testers can write simple, isolated unit tests for each integration in their application and generate API contracts that are guaranteed to be up-to-date with their code, ensuring all dependencies are always compatible.

This unit test approach is simpler, faster and more reliable than traditional end-to-end acceptance tests for a variety of use cases, and can be integrated easily into a holistic testing strategy.

Who should use Pactflow and why?


Pactflow is designed for developers, QA teams and engineering managers who are building, testing and supporting distributed systems - such as web applications based on a microservices architecture.

Modern product engineering typically involves numerous, often distributed teams, requiring an effective collaborative workflow to evolve the design of their APIs.

Pactflow addresses this challenge, by enabling a seamless workflow to share contracts between teams, visualise their dependencies and integrate their CI, whilst reducing the administrative burden of managing extra servers for tooling.

What are some typical use cases?


  • HTTP based API microservice architectures
  • Event based architectures based on message queue and publish-subscribe, such as Kafka, AWS Kinesis, Azure Event Hub
  • Cloud based applications, including use of FaaS products such as AWS Lambda, Azure Functions Google Cloud Functions
  • Data engineering - making implicit contracts in streaming data pipelines explicit, and ensuring contract enforcement between components
  • High performance APIs with protocol buffers
  • IoT - high volume messaging from sensors and devices

What languages does it support?


  • JVM - Java / Kotlin / Groovy / Swift / Scala
  • Ruby
  • Golang
  • NodeJS / JavaScript
  • Python
  • Objective-C / Swift
  • .NET
  • PHP

Can I test cloud services such as Lambda, Kinesis?


Yes - see above!

Can I use it with Message Queue technologies?


Yes - see above!

How does it work with Pact and Spring Cloud Contracts?


Pact and Spring Cloud Contracts are API contract-testing tools that produces contracts. Pactflow manages the lifecycle of these contracts, and provides a workflow to manage them in your continuous delivery pipelines.

Is it compatible with the Open Source Pact Broker?


Yes, we a fully backwards compatible with the Open Source Pact Broker. We contribute regularly to the Open Source roadmap, and generally release multiple updates a week to our customers.

If you need help migrating from a self-hosted broker, please contact us at hello@pactflow.io

Support

Questions around pricing plans

How can I upgrade from the Developer (free) plan?


If you need to migrate data, just drop us a note at hello@pactflow.io and we'll take it from there.

Do you store any credit card information in your systems?


No. All credit card activity and information is handled by our third-party provider, Stripe. See Stripe’s Terms and Services.

How does the team plan work?


The Team plans use a "seat" based model, where you purchase capacity for how many Users you need and assign them as required.

A user is considered any person or system that requires independent access to the system. For example, if you have two team members Sally and Billy that will be logging into the UI, as well as a separate dedicated CI user for automation, they will each consume one seat for a total of 3.

Each user gets a read-only and read-write API token that can be used for automation (e.g. for use in CI or local verification testing). Each user is able to rotate these tokens as needed.

Can each team member see applications and integrations created by other users?


Yes. All users contribute to the same system, they are simply separately authenticated.

What are the various authentication modes?


Users may login with their GitHub credentials (via OAuth2) or standard login (user/pass)

For CLI automation, any user may also create API tokens for use by standard Pact Tooling

Can I migrate my self-hosted Broker to Pactflow?


Yes you can. If you'd like to retain your historical data, contact us at hello@pactflow.io and we'll help you through the process.

Security

Questions around security and data protection

How secure is your solution?


We take security seriously. In addition to 3rd party penetration testing, we perform regular security scanning of our platform, encrypt all data at rest and use TLS for all remote communication. Each customer is further isolated via separate database instances.

Can I host my own Pact Broker?


Yes, you can manage your own Pact Broker, however you will be responsible for its operation, including security, maintenance and upgrades. Pactflow is a fully-managed, highly-available, and hardened deployment of the open source version with an improved user experience.

While we don't currently provide an option to host the commercial product on-premise, contact us if you'd like to discuss this further.

Do you provide a list of IP addresses/ranges that we can use to lock down access to our (CI) systems?


Yes, the following are our registered IP addresses which can be used to lock down access into your platforms:

  • 13.210.164.235
  • 13.210.66.183
  • 13.211.59.138
  • 13.54.130.12
  • 54.252.242.229
  • 54.66.180.72
  • 13.236.113.160
  • 54.252.233.246

Does the underlying data store encrypt, or otherwise protect, the published pacts?


Yes there are a number of strategies we employ, which can be briefly summarised as follows:

  • We use AWS as our underlying infrastructure stack, and follow the guidelines of the Well Architected Framework including standard security protocols
  • Each customer on the platform has their own isolated database with separate sets of credentials
  • All data is encrypted at rest
  • No customer has access to other customers' data
  • We recommend that contracts do not contain any sensitive data (e.g. PII) and contain structural example content only, using tools like Faker.

What will Pactflow do with the contracts or any other data that is uploaded to the service? Will they be harvested and/or shared in any way?


We don't share the data with any third party, anonymised or otherwise. To provide our service, we of course need to analyse the contents of pact files and other interactions with our service to be able to provide the features. All data is encrypted at rest, and no customer has access to other customers' data.

Please read our terms and conditions for further clarification on our non-disclosure policy.

How can we protect secrets we put into the Pact Broker required to get the webhooks to work?


At the moment, webhook secrets are stored in our database in clear-text (as per the OSS version), however we do follow a number of standard security protocols for the hosted environment (see above).

We currently suggest that any tokens in the broker are appropriately scoped in nature, and cycled as per standard security best practices. We have it on our roadmap to address this, however we can’t provide a timeline for this feature at this time.

What are the ways we can best manage our own inbound and outbound access re: the Pact Broker and our hosted CI server?


For user (and system user) access, as it stands, there is just one mechanism: two principles - a read-only and read-write user authenticated via Basic Authentication. We are currently working on implementing social login via GitHub and other providers, as well as SAML authentication in the future. We expect to have this feature production ready early in 2019. If you would like to be involved in an early beta program, or have feedback for our roadmap we would love to hear it.

In terms of network access, the only deployment topology supported is HTTP+TLS access over the public internet.

Ready to get started?