Version & Component Sync for Jira

Seamlessly share versions and components between projects

Git Flow Chart

Bring your commits to life by using the Git Flow Chart to visualise the relationship between branches

Add-ons for Atlassian Jira, Bamboo and Bitbucket

These companies are using CollabSoft add-ons to get the most out of Atlassian Jira


Version & Component Sync

The Version Sync for Atlassian Jira add-on helps project managers to share versions between multiple Jira projects. The goal is to make project administration easier and to allow project managers to spent less time setting up their issue tracker and focus on the actual issues.

Creating a project link

Versions are propagated from one master project to multiple linked projects.

Given we have a Jira instance with a Demonstration Project (DEMO), a My Project (MP) and My Other Project (MOP), if we want to share versions from DEMO, we will need to create project links to MP and MOP. In this example, DEMO is our master project.

  1. Go to the Administration interface of the DEMO project. You will see a new Version Sync panel on the summary page below the Versions panel
  2. Click on the Add Project Link button to open the project link lightbox.
  3. Select the project from the drop-down Versions from DEMO will be propagated to this project
  4. Choose the type of synchronisation You can choose between Full Synchronisation or Specific Changes.
  5. Click on the Add Project Link button

Understanding project links

There are a few considerations when creating a project link: It is effective immediately, meaning that it will start synchronising versions as soon as the project link is created. In case of full synchronisation, the add-on will delete any version in the linked project that does not exist in the master project.

You can create multiple project links for one master project (e.g. DEMO can have project links to MP and MOP). It is however not possible to have project links to a project that is already linked to another project or acts as a master project. For instance, if we have a link between DEMO and MP, we cannot create a project link to DEMO or MP with MOP as the master project.

In case of Full Synchronisation, the Versions panel will be removed from the linked projects administration interface. In addition, the create and edit features of the Versions configuration screen will be disabled. Linked versions will be marked with the Version Sync icon.

Synchronisation types

When creating a project link, you can choose between Full Synchronisation or synchronisation based on Specific Changes. Full Synchronisation does exactly that. It will disable the ability to create or edit versions from the linked project administration screen and it will propagate any and all version changes from the master project to all linked projects. This includes releasing, archiving, deleting and updating version(s). Synchronisation of specific changes is less rigid. It will still propagate version updates like description and release dates, but it will give you more control over the versions in the linked project. For instance, if you only select the Create event, it will never delete versions from linked projects when they are deleted in the master project. You can still manage versions from the linked project administration screen. This is particularly useful if the project has a mixture of shared versions and project specific versions.

Removing a project link

You can remove project links from the Version Sync panel on the project Administration summary page. Removing a project link will stop the propagation of version changes to the previously linked project. It will not remove any previously shared versions from the linked project. This can be considerate a safe operation.

Disclaimer & Support

Although it can save you a lot of time, the Version Sync add-on can also be very destructive in case it is not configured properly. The Version Sync add-on will alter the linked project version configuration as soon as the link has been created. This can include deletion of versions, which also removes them from any associated issue. Even though we have an extensive set of automated and manual tests that are executed each release it is highly recommended to make a full back-up of your installation. If possible, install it on a non-production Jira instance prior to using it for testing purposes. Make sure you are fully aware of how the add-on configuration works and that you have confirmed that it is configured and working as expected. CollabSoft will not accept any responsibility in regard to the data integrity of your Jira instance.

The Version Sync add-on is fully supported. Please contact us in case of questions, feature requests or bug reports using the contact information provided on the Atlassian Marketplace.

Hipchat User Management

The Hipchat User Management add-on allows Jira administrators to synchronise users from the Jira User Server to a Hipchat account. This will allow system administrators to simplify user management when using both Atlassian Jira and Hipchat in their organisation.

How it works

The Hipchat User Management add-on links your Jira user server with your Hipchat account using the Hipchat API, centralizing your account management and providing more granular control over your Hipchat subscription.

Group-based user administration

You can select which users are added to Hipchat by specifying the Jira groups for Users and Administrators. The Hipchat User Management add-on will only sync users that are in those specific groups.

If no groups are specified, the add-on will synchronize all users from the jira-users and jira-administrators groups.

One-way sync

The add-on only synchronizes Jira users to Hipchat. Hipchat user accounts will not create Jira users. You can use the Calibration Wizard to see orphaned users.

No account deletion

Account management is a delicate task. The add-on will not automate the deletion of user accounts, in Jira or in Hipchat. This is something you should do manually and with great care. We will give you the tools to see which users are orphaned.

Step-by-step explanation

There are 6 fields that can be used to control the behavior of the Hipchat User Management add-on. We will discuss each of them so you get a better understanding of what they do.


This is the hash key for the Hipchat API. We use the API to list and create users.

User group

This is the Jira group which contains the Jira users that will be synchronized with Hipchat. They will get the Hipchat role of "User". If no group is specified, the 'jira-users' group will be used. It is recommended to create a new group called 'hipchat-users'.

Admin group

This is the Jira group which contains the Jira users that will be synchronized with Hipchat. They will get the Hipchat role of "Admin". If no group is specified, the 'jira-administrators' group will be used. It is recommended to create a new group called 'hipchat-administrators'.

Default Job Title

Hipchat requires users to fill in their Job Title. Because we cannot ask this during Sync, we need you to specify the default job title.

Default Password

Unfortunately we cannot synchronize the user password. So we need a fresh new default password when we create a new Hipchat account. Hipchat also does not sent a notification to users created by the API. You will need to inform the user of their new account and sent them the default password to log in.


The automatic account synchronization is disabled by default. If you feel confident that your setup is correct, and wish to take away the extra step of manually synchronizing Hipchat accounts, you should enable this.

Update Interval

The account synchronization runs as a background process. The update interval determines how often it checks for new accounts. To avoid problems with the Hipchat API request limit and Jira performance, it is recommend to keep the update interval limited.

Hipchat gadgets

The Hipchat User Management add-on comes with a "Who is online?" gadget You can add this gadget to your dashboard using the "Add Gadget" button.

Who is online?

Users can add this gadget to their dashboard to check if a specific user is online on Hipchat and available for a quick chat.

Nested Variables

The Nested Variables for Atlassian Bamboo add-on is an extension of the existing Global and Plan variables. It allows system and plan administrators to re-use existing variables. The goal is to make variable maintenance easier and allow Bamboo users to get the most out of their existing variables. In addition, it supports enforcing security where access to global variables is limited to system administrators without adding extra constraints to plan administrators to create their own variables.

Nested variables also allow you to create variables with more than 255 characters, which is the default limit of variables in Atlassian Bamboo. By chaining multiple variables using the Nested Variables add-on you can create a workaround for this limit.

Creating a nested variable

This example assumes you already have Bamboo setup with the Nested Variables add-on and have created a Plan.

You can create a nested variable in three simple steps:

  1. Create a Global or Plan variable. Use helloVariable as key and Hello as value.
  2. Create another Global or Plan variable. Use helloWorldVariable as key and ${bamboo.helloVariable} world! as value.
  3. Create a Job with a Script task which has the following inline script body:
    echo "${bamboo.helloWorldVariable}"
  4. Run the plan and look at the log files. You will see an echo output of Hello world!.

Limits to the use of Nested Variables

Although there is no limit to the number of nested variables or the depth level of the nesting of variables, there are still some limitions that you might want to consider:

  • Nested variables are only substituted during task execution. For instance, you cannot use nested variables in the repository url field, even though you can use regular variables for this.
  • The variable limit of 255 character still applies to the variables fields. In order to create a workaround, you will need to split up the values in multiple nested variables. Each of those variables should stay within the variable value limit.
  • Bamboo does not support variable modifications by add-ons in deployment plans. Due to this limitation, the Nested Variables for Atlassian Bamboo add-on can only be used in build plans.

Project Variables

The Project Variables for Atlassian Bamboo add-on is an extension of the existing Global and Plan variables. It allows plan administrators to create variables that are available to all plans in the project. The goal is to make variable maintenance easier. In addition, it supports enforcing security where access to global variables is limited to system administrators without adding extra constraints to plan administrators to create their own variables.

Creating a project variable

This example assumes you already have Bamboo setup with the Project Variables add-on and have created a Plan.

You can create and use a project variable in three simple steps:

  1. Create a project variable using the Project Configuration screen. Use helloWorldVariable as key and Hello World! as value.
  2. Create a Job with a Script task which has the following inline script body: echo "${bamboo.helloWorldVariable}"
  3. Run the plan and look at the build log. You will see an echo output of "Hello world!".

Limits to the use of Project Variables

Although there is no limit to the number of project variables, there are still some limitions that you might want to consider: Project variables are only substituted during (remote) task execution. For instance, you cannot use project variables in the repository URL field.

If you do wish to use them in other parts of your configration, please note that Project variables are actually an extension to global variables. If you wish to use the Project variable in the repository URL field, you can do so by using the following notation: ${bamboo.PROJECTKEY.variableName}.

Replace "PROJECTKEY" with the upper-case value of the project key and "variableName" with the name of the variable you wish to use.

Automatic Retry

The Automatic Retry add-on for Atlassian Bamboo is a build utility that will automatically restart or re-run failed/incompleted jobs. Bamboo administrators can use Automatic Retry for plans that have a dependency on the availability of 3rd party services (like FTP/SSH). If the service is temporary unavailable and the build fails because of it, the Automatic Retry add-on will reschedule the job without supervision. If the service becomes available again, the job will finish successfully. Automatic Retry can also help with other environment specific issues like remote agents that go offline, memory or CPU performance issues or network outages.

System administrators can create retry configurations which determine how often a automatic retry will be scheduled, the timeout between each retry and if a re-run of the entire plan is performed when a job continuous to fail.

Creating a retry configuration

This example assumes you already have Bamboo setup with the Automatic Retry add-on and have created a Plan.

You can create a retry configuration in two simple steps:

  1. Go to the Auto Retry add-on configuration screen in the Bamboo Administration interface
  2. Add a Retry Configuration using a descriptive name, the preferred number of retries, the timeout in seconds between retries and the plan to which the retry configuration should apply.

The retry configuration will be evaluated each time a job fails. If the plan is part of the retry configuration the job execution will be rescheduled.

Testing the retry configuration

In order to test the Automatic Retry add-on you can create a Job in a plan which is part of a retry configuration with a Script Task which has the following inline script body (Bash example):

echo "This task will fail"
sleep 10s
exit -1

Run the plan and watch it fail. On the build result summary page an Automatic Retry status panel should appear which will show the number of retries left and the date / time the next retry is scheduled.

The Automatic Retry add-on will not reschedule jobs that were manually stopped.

Git Flow Chart

Many teams use Git flow as their branching strategy and development workflow. It is commonly explained using a colorful chart that shows the master and develop branches as vertical lines with the feature branches to one side and relase and hotfix branches between them.

If you run 'git log --graph' on a repo or when you look at the graph in a UI tool like SourceTree, the chart looks nothing like the git flow graph. The straight vertical line is not necessarily the master or develop branch. It is very hard to see if everyone is correctly following the branching pattern or if something odd has happened.

Git Flow Chart draws your commits as the chart explaining git flow. This will give much better insight in the current state of the repository, showin the feature branches as straight lines branching from develop and merging back when finished. Color coding indicates whether a commit is on a feature branch, a release branch or on develop or master.

For better insight in what is part of a specific feature branch, you can click any commit to highlight all commits and branch lines that are part of its ancestry. This is especially useful when you have many parallel feature branches. Of course, you can also click through to the standard Stash commit details.

Installation & Usage

You can install the Git Flow Chart add-on using the Universal Plugin Manager from the Stash administration screen. After installation, a new navigation item called "Git Flow Chart" becomes available when browsing a repository.

The Git Flow Chart will create the initial tree graph using the most recent commits. While scrolling down the page, the graph will automatically collect more details as soon as it detects that it cannot draw the parent of one of the visible commits. A progress indicator is shown while loading new information and updating the graph. Please note that, depending on the complexity of the commit history, the UI might freeze while rebuilding the graph.

If you wish to zoom in on the inheritance tree of a specific commit, you can click on the commit message. This will highlight the commit and it's known parentage. You can undo the selection by clicking on the highlighted commit.

Because building the Git Flow Chart is complex, the information displayed might sometimes seem a bit odd. Please read the FAQ to see if there is anything you can do to improve the correctness of the graph.


Can I use Git Flow Chart when we don't (strictly) follow git flow?

Yes, no problem. If you don't always use feature branches or if you branch your feature branches off from master and don't use a develop branch, Git Flow Chart will still give you better insight in the state of your repo than most charts. If you commit everything on master and your flow is basically linear, there is not much value to the chart.

Does Git Flow Chart support non-standard naming conventions?

Yes, by default, the chart uses 'develop' for the develop branch and 'feature/', 'release/' and 'hotfix/' prefixes. If you use other names, you can change these defaults in the repository settings screen.

Why is the chart not 100% correct?

Git does not keep track of the history of branches. Branches are a moving label pointing to the HEAD (current) revision of the branch, but git keeps no historic information of which commits have been the HEAD of a branch in the past. So if you want to draw the develop branch as a line, you are essentially guessing. The last commit is certain, but whenever a commit has multiple parents, we have to make an educated guess on which parent was on develop and which commit was a merged in feature or release branch. If you keep strictly to git flow, there must be one 'true' develop line, but it can be hard to decide which it is. Git Flow Chart uses many hints in these decisions, including the commit messages on merges. It helps to keep the unchanged commit messages as git would suggest them.

My master branch is not correct

In git flow, the master branch is normally easier to isolate than the develop branch, because all of the release tags must be on it. The algorythm assigns large weight to tags that look like a release tag. By default, it uses the form x.x[.x[.x]] where x can be one or more digits. If your release tags look different, you can enter an appropriate regular expression in the repository settings screen.

I see multiple develop branches. How come?

This may seem strange, but is actually normal. If multiple developers work on the repo at the same time, they don't always have their local develop branches synchronized. When they commit on develop and later pull/push, they will have multiple develop lines, joining again at the implicit merge that happened when they pulled. Git Flow Chart tries to recognize these situations and will draw multiple develop lines. When it fails to recognize this situation, part of the develop branch might appear like a feature branch.

The chart draws commits on develop that were on a feature branch when I made them

In general, see the previous FAQ ('Why is the chart not 100% correct?'). Specifically, when a feature branch is merged back to develop using fast-forward merging, the commit is actually on two branches: on the feature branch AND on develop. Git Flow Chart picks develop over the feature branch in these cases. So a feature branch with only one commit that is immediately merged back using fast-forward will appear as a direct commit on develop.

The javascript code is on GitHub, is Git Flow Chart Open Source?

No, it is not. If you are using the code in a commercial instance of Atlassian Stash, you will need to purchase a license. Atlassian does have great offers for Open Source projects or Academic users. However, we do want to share the code and allow you to inspect, study and contribute improvements. For that reason, the core code of Git Flow Chart is hosted on GitHub. It is a javascript library and comes with unit tests and a standalong HTML page that allows you to test improvements locally. Feel free to fork!


Service Level Agreement

CollabSoft provides customer support for all add-ons listed on the Atlassian Marketplace. If you find yourself in need of support, you can create a support request using the Service desk customer portal.

Customer Support policy

It is our intention to respond to support requests within 1-3 business days (excl. official Dutch holidays). Our office times are Monday to Friday, 9AM to 5PM CET. As a small marketplace vendor it can prove difficult to provide enterprise-grade support. As such, we appreciate your patience with our support process. We will try our best to help you solve the problem, but cannot guarantee that we can provide a solution for each specific issue.

Add-on support includes help with issues during installation, upgrades and add-on usage. It does not include training, help with Atlassian product issues, support for older non-supported versions of the add-on or non-english support requests. We will try to help customers without a valid and current license on a best-effort SLA without any guarantees of solving the issue.

Atlassian product compatibility policy

CollabSoft add-ons are only supported for Atlassian products that have not yet reached End of Life status. Please consult the Atlassian Support End of Life Policy page for a list of currently supported product versions.

In terms of Atlassian product compatibility for supported Atlassian product verions, we try to adhere to the requirements listed in the Atlassian Verified Program. Unfortunately, it is impossible to continue to provide support for breaking changes in Atlassian products. As such, breaking changes to (private) Atlassian product API will result in the release of a new version of the add-on and retirement (End of Life) of previous add-on versions. It is strongly recommended to make sure CollabSoft add-ons are used in combinations with the latest version of Atlassian products.

CollabSoft add-ons are released with a [MAJOR].[MINOR].[PATCH] versioning scheme, also known as Semantic Versioning. Backwards compatibility is only guaranteed for [PATCH] versions. Breaking changes may be introduced in [MAJOR] and [MINOR] versions without providing an automated upgrade path and without prior warning.

List of offical Dutch holidays 2017-2020

  • New Years Day (January 1st)
  • Easter Monday (April 17th, 2017. April 2nd, 2018. April 22nd, 2019. April 13th, 2020)
  • Kingsday (April 27th)
  • Ascension Day (May 25-26, 2017. May 10-11, 2018. May 30-31, 2019. May 21-22, 2020)
  • Pentecost Monday (June 5, 2017. May 21th, 2018. June 10th, 2019. June 1st, 2020)
  • Christmas (December 25-26)

Last updated: December 19, 2016

Privacy, Security & Cookie Statement

CollabSoft does not collect, store or process any private/sensitive information in the add-ons suitable for Atlassian server products, nor does it collect, store or process any analytical or tracking data, or place cookies or tracking beacons in any add-ons suitable for Atlassian server products.

Any personal information required for licensing and billing is collected and processed by Atlassian and is governed by the Atlassian Marketplace Terms of Use and the Atlassian Privacy Policy. CollabSoft has access to personal and billing information as part of the reporting and analytics features provided by Atlassian to Marketplace vendors.

This information can be used for analysis and improvement of the CollabSoft website and add-ons. It may also be used to contact you regarding service updates of add-ons for which you are listed as the technical contact. CollabSoft may use 3rd party services for such communications, in which case it will ensure that a Data Processing Agreement is in place (in accordance with EU Data Protection laws).

Google Analytics is used by Atlassian to collect usage information on the Atlassian Marketplace add-on listing pages. Any private information collected by Atlassian or third party partners on the Atlassian Marketplace website is governed by the Atlassian Privacy Policy. Although CollabSoft does receive Google Analytics data from the Atlassian Marketplace website, it does not control the collection, storage and processing of such information.

Google Analytics is also used for collecting usage information regarding the CollabSoft website(s). A tracking cookie may be placed by Google to enable the collection of analytical data. The information collected is stored anonymously. No other cookies or tracking technologies are used by CollabSoft.

CollabSoft uses Atlassian Jira Cloud with Jira Service Desk to provide customer support. Customers who wish to contact Collabsoft support are required to create an Atlassian ID account. Any personal information requested in the account sign up process will be collected, stored and processed by Atlassian and is governed by the Atlassian Privacy Policy.

If you have any questions or comments as a result of this privacy statement, please use the contact form to send a message.

Last updated: January 23, 2018

End-User License Agreement

This End-User License Agreement (herinafter referred to as EULA) is a legal agreement between you (either and individual or single entity) and Software Defined Everything B.V., operating under the registered trademark CollabSoft (hereinafter referred to as COLLABSOFT).

By installing, copying or using any of the COLLABSOFT add-ons (hereinafter referred to as ADDON), you agree to be bound by the terms of this EULA.

This EULA is a supplement to the Atlassian Marketplace Terms of Use Standard EULA (hereinafter referred to as STANDARD EULA), the Service Level Agreement (hereinafter referred to as SLA) and the Privacy, Security & Cookie Statement (hereinafter referred to as PRIVACY STATEMENT). By agreeing to the terms of this EULA, you also agree with the STANDARD EULA, the SLA and the PRIVACY STATEMENT.

The contents of this EULA suppercedes any conflicting provisions in the STANDARD EULA, the SLA and/or the PRIVACY STATEMENT. When reading and interpreting these documents, they should be read in the following order: 1) EULA, 2) PRIVACY STATEMENT, 3) SLA, 4) STANDARD EULA. In case of conflict between these documents, the provision in the document with the highest order prevails.

If you do not agree with the EULA, you are not authorized to install, copy or use the ADDON and will immediately uninstall and remove any previously installed or acquired copies. Obtaining the ownership of the material support of the software only, shall not grant you any right to install, to copy, to use, or to otherwise exploit the ADDON.

1. Limited warranty

COLLABSOFT will use reasonable commercial efforts to provide solutions for any reported malfunctions. THIS IS A LIMITED WARRANTY AND IT IS THE ONLY WARRANTY MADE BY COLLABSOFT. COLLABSOFT MAKES NO OTHER WARRANTY, REPRESENTATION, OR CONDITION, EXPRESS OR IMPLIED, AND EXPRESSLY DISCLAIMS THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NO INFRINGEMENT OF THIRD PARTY RIGHTS. THE DURATION OF IMPLIED WARRANTIES OR CONDITIONS, INCLUDING WITHOUT LIMITATION, WARRANTIES OR CONDITIONS OF MERCHANTABILITY AND OF FITNESS FOR A PARTICULAR PURPOSE, IS LIMITED TO THE ABOVE LIMITED WARRANTY PERIOD; NO COLLABSOFT PARTNER, DISTRIBUTOR, OR EMPLOYEE IS AUTHORIZED TO MAKE ANY MODIFICATIONS, EXTENSIONS, OR ADDITIONS TO THIS WARRANTY. If you make any modifications to the SOFTWARE PRODUCT during the warranty period, if the media is subjected to accident, abuse, or improper use, or if you violate the terms of this EULA, then this warranty shall immediately be terminated. This warranty shall not apply if the SOFTWARE PRODUCT is used on or in conjunction with hardware or software other than the unmodified version of hardware and software which the Software was designed to be used as described in the Documentation.

2. Limitation of liability


3. Copyright and Infringement Indemnification

All intellectual property rights in and to the SOFTWARE PRODUCT and Documentation are property of COLLABSOFT. All intellectual property rights related to the SOFTWARE PRODUCT remain property of COLLABSOFT. Dutch copyright law, local copyright law and international treaties protect the SOFTWARE PRODUCT as well as the rights related to it.

COLLABSOFT will hold You harmless, defend and indemnify You, against a third party claim to the extent based on an allegation that the SOFTWARE PRODUCT infringes a third party intellectual property right, provided that COLLABSOFT: (i) is promptly notified and furnished a copy of such Claim, and all other documents that the claim is based on (ii) is given reasonable assistance in and sole control of the defense thereof and all negotiations for its settlement.

COLLABSOFT will have no obligation to defend and no liability for any damages or costs to the extent that a Claim is based upon: (i) use of the SOFTWARE PRODUCT in combination with any non-COLLABSOFT product, software or equipment; (ii) use of the SOFTWARE PRODUCT in a manner or for an application other than for which it was designed or intended to be used, regardless of whether COLLABSOFT was aware of or had been advised of such use; (iii) modifications to the SOFTWARE PRODUCT by any person or entity other than COLLABSOFT;

If the SOFTWARE PRODUCT becomes, or in the opinion of COLLABSOFT may become, the subject of a Claim, COLLABSOFT may, at its option and in its discretion: (i) procure for You the right to use the SOFTWARE PRODUCT, free of any liability; (ii) replace or modify the SOFTWARE PRODUCT to make it non-infringing; or (iii) terminate your right to continue using the SOFTWARE PRODUCT and refund, in this case, any license fees related to the SOFTWARE PRODUCT paid by You.

This EULA represents the complete agreement concerning this license between the parties and supersedes all prior agreements and representations between them. COLLABSOFT may amend or modify this EULA at any time without having to notify you or obtain your prior approval. However, ammendments and modifications to the EULA will only take effect upon purchasing or renewing the ADDON license.

COLLABSOFT has the right to use Your name for commercial purposes and/or to include your name and/or logos in his clients list. COLLABSOFT will stop using Your name and/or logos upon request.

If any provision of this EULA is held to be unenforceable for any reason, such provision shall be reformed only to the extent necessary to make it enforceable and the remaining provisions of this EULA shall remain in full force and effect.

Neither this EULA, nor any terms and conditions contained herein, shall be construed as creating a partnership, joint venture or agency relationship or as granting a franchise. You shall, at your own expense, promptly obtain and arrange for the maintenance of all mandatory government approvals, if any, and comply with all applicable local laws and regulations as may be necessary for your performance.

This EULA and any other agreement with COLLABSOFT will be governed by Dutch law.

Last updated: December 16, 2016


If you're looking at this section, it probably means that you are in need of support. Let's us start by saying that we are sorry that you are in need of assistance. Hopefully it is a minor issue which we can fix in a jiffy.

We are using Atlassian Jira Service Desk for all support requests. You can create new support requests and review the status of existing requests in our Customer Portal.

A service desk account and a valid SEN number are required for creating support requests. You can create an account using the "Sign up" button.

Report issue Sign up


Feel free to ask!

If you have any other question, please use the form below to sent us a message.
We will contact you as soon as possible.

Software Defined Everything B.V.
Postbus 92298
1090 AG Amsterdam