Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

What do you think about a hybrid Server/Cloud approach for Apps like Meetical for Confluence?

Lukas Gotter _ Meetical
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
October 14, 2019

Meetical is a new Confluence App we released in September 2019 to the public after test driving it with pilot customers. Update: In May 2020 we released the all new Cloud Version to improve Meeting Notes Management in Confluence.

We are using a hybrid Server/Cloud approach for the Server App. What do you think about that?

I will briefly explain the problem area and solution approach before I discuss the technical approach. The goal is to hear the community's opinion.

Intro / Problem:

Usually meeting pages in Confluence are created manually (or are not created at all because you lack time). This leads to unnecessary repetitive work, and often outdated and hard to find meeting pages. The new App helps you to avoid just that, by saving you time and simplify your meeting preparation and documentation through automation and Calendar Integration. (Thanks for reading this pitch, I think it's important to see the whole  context)

In order create pages from your calendar events, we enable you to connect your Calendar to Confluence via OAuth and REST APIs.


Instead of copy-pasting information from your calendar, we want you to be able to create pages directly from your events with a single click (if possible). We also update the confluence meeting page, if the event changes with the Help of Push Notifications. To do all that and more, we run a Cloud Service on Heroku (developed with with Spring Boot). 

Technical Approach - Hybrid Server/Cloud

Meetical works with Confluence Server (on premise) and Confluence Cloud (since May 2020). However, both the Server and Cloud Version of the Meetical Confluence App needs access to the Meetical Online Cloud Service running at (on port 443).

The Cloud Creator Service is responsible to initially authenticate the users, allow them to share their calendar via industry standard security OAuth, as well as allowing the App to create and update Confluence pages on their behalf. No operational data is stored on that service, all your business data remains on your calendar and on Confluence. The Cloud Service only does the processing. (Also check our Terms and Conditions for details on our design goals).  

If your Confluence instance is reachable from the Internet, you are usually fine. If you are behind the firewall, you need to configure a firewall rule and allow access to your Confluence from our Online Service, so we are able to use the Confluence REST API.

Using this combined approach comes with a few advantages:

  • On your side you will have nearly zero Configuration. You and your Colleagues / Users will log in with both your Confluence and Calendar Accounts, grant access to the required resources and you are ready to go! - If you would run the Sync Services yourself, you would for example need to create an OAuth Client ID and go through a verification process with Google or Microsoft.
  • Furthermore, we can deploy Improvements and Bugfixes continuously and fast without your need to always update the Confluence App. (However, some bigger updates will still require you to update the App)
  • Moreover, your Confluence Instance Performance is not affected by change tracking and sync processing, because we run all change tracking and sync services for you. We use the Confluence REST API to interact with your instance to process updates.

On the other side, using our Cloud Services also means you need to give us access to your calendar and confluence systems and potentially rises security and privacy concerns.

To minimize security issues and privacy concerns we both apply modern cryptographic approaches (RSA with OAuth1a for Atlassian APIs, and OAuth2 for Google APIs - everything over SSL of course) and furthermore we minimize the data we permanently store on our side. In fact, we never store any content like page titles, event dates, attendees etc. on our side. Currently even the ID mapping is saved on your Confluence Server. As a side note, caching mechanisms, however will temporary save such data. But basically, we only match your calendar events with your confluence pages and do the rest of the calculation on-the-fly.

Are some of these arguments, or any other concern a showstopper for you to implement a solution with such an approach at your company? Could a hybrid approach generally help to see increasing Cloud Product adoption ob bring the best of two worlds to customers?


If using our Cloud Services is still not an option for you, we can offer that you get in contact with us so we can evaluate running the Sync Service on your infrastructure and behind the firewall.

Furthermore, if we see increasing interest from the community, we might offer a fully integrated Confluence App as well. 

Finally, let me mention that we are working on the Meetical Cloud Version, for those Customers using Confluence Cloud. We will announce it also via our Mailing List when it's available and I keep note to add a comment here as well, so stay tuned. (Update: Released in May 2020 after an extensive Beta).

Thank you for reading and your interest in Meetical. What do you think about this hybrid approach? Let me know any further questions here or via 

Have great meetings,


1 comment


Log in or Sign up to comment
Deleted user October 30, 2019

hi @Lukas Gotter _ Meetical here you find a version that explains in Italian my impressions about your plugin that I think is very useful, it solves just one of the most known problems of the meeting notes of Confluence

AUG Leaders

Atlassian Community Events