Enterprise local sync solution
In case your Enterprise account needs complete control over your published content, we support the option to manually download separate projects from the dashboard as a ZIP-file. These ZIP-files will be compressed per project which you can extract and host on your local server. This option is normally used for back-up purposes. When you are running a live environment however, where projects are continually changing, we can offer a direct synchronisation between our Maglr servers and your local server. Click here to see how this works in practice.
**
By default, all content is uploaded and published within the Maglr platform. When a project gets published, all assets are pushed to different worldwide CDN servers. For enterprises and companies who would like to host the published content on their local servers, we can create an FTP/SFTP connection or push to AWS S3.
Note: an FTP/SFTP/S3 connection is made to copy or synchronise files between servers
This synchronisation could be helpful when:
an employee is creating publications and uploading content to our Maglr servers, and is using our Maglr platform and its editors to create new projects;
content is secured and served from the Maglr dashboard when previewing, only available for admins who are logged in;
the originally uploaded assets (images, videos, PDF's) are not publicly available. Only admins logged into the dashboard can view and download these assets.
you need to host a publication elsewhere, as soon as a project is set active and published. The platform will not send the assets (HTML/ js/resized images) to the CDN servers, but it is pushed -_with an FTP/SFTP/S3 connection_- to the local server environment of the client.
you are making updates. The sync connection is pushing the changes that are made from another server.
Customers using an Enterprise license can activate this functionality in the dashboard. This requires a one-time configuration from Maglr. The sync uses a basic FTP/SFTP or S3 solution for which we can configure various security methods.
A local server with FTP access, possibly limited to a root directory, is a requirement along with optional url-rewrite support for the management of the URL redirect structure.
Within Maglr, we activate a preview domain in the dashboard. This allows publications to be tested on Maglr's servers at an early stage, which prevents waiting times with having to synchronise data to your own server.
Once ready for production, we configure a second domain which is the final destination on your own local server. In the Maglr dashboard, this production domain is communicated in different screens where an employee simply copies the exact link after the publication has been fully synchronised.
For more technical information about this integration, please contact info@maglr.com.
The synchronised version that is running on the local server of the client is completely static. This means that in case our Maglr servers would (potentially) go down, the local version will still work and is not affected.
Keep in mind: the published synced content is a static minimised version of the original source material. To make edits to these publications, you would still need the editors including the Maglr platform to make changes. Updates of our code (that changes on a monthly basis) are only pushed when you are making new updates or synchronisations to these projects.
When publishing and then exporting the publication to your own server, the following components are placed on the server. Publishing is always done per project.
For each project, a folder is placed in the configured / root folder of the main domain containing the pages of the project. The folder name is the same as the URL of the project, which is configurable through the project settings.
A separate html page is generated for each page. The Maglr publication works largely in javascript. The pages are rendered especially for search engine optimisation. This is because search engines cannot always index javascript websites properly. A pre-rendered page contains all set metadata and is easy to read for search engines.
All necessary assets including resized images, audio files, video files and compressed minified html & js are synced to the local server.
Complete URLs with history. The URL structure is identical to that of the online version. URL names that are changed via the page settings of a project are copied 1 on 1. With every export, all URLs, including historical URLs, are stored in a .htacces file. Old indexed URLs in for example Google can be forwarded to the new URL.
A robots.txt file will be posted. If it is indicated via the navigation environment settings that indexing by search engines is not allowed, this will be configured in this file.
A sitemap.xml where search engines have a quick overview of all current URLs of a publication.
The root folder configured for Maglr, accessible through FTP :
www.companyname.com/publications
When a project with the name 'annual-report' is synced, we add a folder inside 'publications'
www.companyname.com/publications/annual-report
Inside this project we add a static HTML file per page. Depending if you choose for URL rewrites, the final URL will look like this:
www.companyname.com/publications/annual-report/figures.html
We offer two choices when publishing the projects for your server. A complete static set-up, built up from static HTML files. And a version with extra URL rewrites. The most important functionality of this option is redirecting old URL's to new versions.
Inside the dashboard a user could change the name of the page. Through the synchronisation proces the html file of the page might change causing a 404 error when the URL is already indexed in Google.
When URL rewrites are activated we can detect the URL is not working anymore and redirect the visitor to the new URL of this page. In each update we add a configuration with all earlier published URL's and the new versions.
At this moment URL rewrites are available for Linux servers (apache / nginx) and Windows servers (IIS / web.config. AWS S3 would need an additional Lambda function, for other server environments we might need to publish the config in a different format. Contact us for more information about this topic.
The most common method is using a FTP/SFTP to sync data to your server. We are also able to push the content into a S3 bucket. When using the static HTML version this would work out of the box. When you need URL rewrites / redirect it is possible in combination with a AWS Lambda function.
This option might need some extra help. Contact us for questions or requirements in combination with other storage options.
When creating a project you are first able to test and preview the content through a local Maglr domain (customer.maglr.com). As soon as the project is ready and you hit the publish button assets will be synchronized to your corporate server.
You can make changes in between but also put a project offline. We move the content so it's not publicly available anymore.
The amount of space you would need depends on the type of publication. A lot of assets or maybe videos require more space. In global a publication with around 10 pages would require +/- 50MB.
The data traffic depends on the amount is visitors. Since all content is static it's easy to serve it to bigger numbers in combination with a CDN.
When the content is running on your server you are able to add custom security integrations (corporate employee login for example). As the Maglr content is static and does not require additioneel server components lot's of options are available.
When we push content to your storage server we need to configure the correct credentials. Because Maglr is hosted AWS, in a 'floating' Cloud set-up, we do not have a static IP. For this reason it's not possible to add our servers in a firewall configuration.
Information we need for each different connection type:
FTP: the most basic method requires a username + password.
SFTP: we provide a 'Public key' you can configure on your server. When configured we need a username with a (optional) password.
AWS S3: pushing content directly to a S3 requires a configured bucket. To connect to a bucket we need the region, key, secret-key and name of the bucket.
Note: this option is only available with the Maglr Enterprise license. This option requires a one-time set-up, depending of the type of synchronisation and IT requirements.
**How does this synchronisation work?
By default, all content is uploaded and published within the Maglr platform. When a project gets published, all assets are pushed to different worldwide CDN servers. For enterprises and companies who would like to host the published content on their local servers, we can create an FTP/SFTP connection or push to AWS S3.
Note: an FTP/SFTP/S3 connection is made to copy or synchronise files between servers
This synchronisation could be helpful when:
an employee is creating publications and uploading content to our Maglr servers, and is using our Maglr platform and its editors to create new projects;
content is secured and served from the Maglr dashboard when previewing, only available for admins who are logged in;
the originally uploaded assets (images, videos, PDF's) are not publicly available. Only admins logged into the dashboard can view and download these assets.
you need to host a publication elsewhere, as soon as a project is set active and published. The platform will not send the assets (HTML/ js/resized images) to the CDN servers, but it is pushed -_with an FTP/SFTP/S3 connection_- to the local server environment of the client.
you are making updates. The sync connection is pushing the changes that are made from another server.
What is needed for this integration?
Customers using an Enterprise license can activate this functionality in the dashboard. This requires a one-time configuration from Maglr. The sync uses a basic FTP/SFTP or S3 solution for which we can configure various security methods.
A local server with FTP access, possibly limited to a root directory, is a requirement along with optional url-rewrite support for the management of the URL redirect structure.
Within Maglr, we activate a preview domain in the dashboard. This allows publications to be tested on Maglr's servers at an early stage, which prevents waiting times with having to synchronise data to your own server.
Once ready for production, we configure a second domain which is the final destination on your own local server. In the Maglr dashboard, this production domain is communicated in different screens where an employee simply copies the exact link after the publication has been fully synchronised.
For more technical information about this integration, please contact info@maglr.com.
Local version not editable
The synchronised version that is running on the local server of the client is completely static. This means that in case our Maglr servers would (potentially) go down, the local version will still work and is not affected.
Keep in mind: the published synced content is a static minimised version of the original source material. To make edits to these publications, you would still need the editors including the Maglr platform to make changes. Updates of our code (that changes on a monthly basis) are only pushed when you are making new updates or synchronisations to these projects.
What do we sync to your external server?
When publishing and then exporting the publication to your own server, the following components are placed on the server. Publishing is always done per project.
For each project, a folder is placed in the configured / root folder of the main domain containing the pages of the project. The folder name is the same as the URL of the project, which is configurable through the project settings.
A separate html page is generated for each page. The Maglr publication works largely in javascript. The pages are rendered especially for search engine optimisation. This is because search engines cannot always index javascript websites properly. A pre-rendered page contains all set metadata and is easy to read for search engines.
All necessary assets including resized images, audio files, video files and compressed minified html & js are synced to the local server.
Complete URLs with history. The URL structure is identical to that of the online version. URL names that are changed via the page settings of a project are copied 1 on 1. With every export, all URLs, including historical URLs, are stored in a .htacces file. Old indexed URLs in for example Google can be forwarded to the new URL.
A robots.txt file will be posted. If it is indicated via the navigation environment settings that indexing by search engines is not allowed, this will be configured in this file.
A sitemap.xml where search engines have a quick overview of all current URLs of a publication.
Example set-up
The root folder configured for Maglr, accessible through FTP :
www.companyname.com/publications
When a project with the name 'annual-report' is synced, we add a folder inside 'publications'
www.companyname.com/publications/annual-report
Inside this project we add a static HTML file per page. Depending if you choose for URL rewrites, the final URL will look like this:
www.companyname.com/publications/annual-report/figures.html
URL rewrites for redirects
We offer two choices when publishing the projects for your server. A complete static set-up, built up from static HTML files. And a version with extra URL rewrites. The most important functionality of this option is redirecting old URL's to new versions.
Inside the dashboard a user could change the name of the page. Through the synchronisation proces the html file of the page might change causing a 404 error when the URL is already indexed in Google.
When URL rewrites are activated we can detect the URL is not working anymore and redirect the visitor to the new URL of this page. In each update we add a configuration with all earlier published URL's and the new versions.
At this moment URL rewrites are available for Linux servers (apache / nginx) and Windows servers (IIS / web.config. AWS S3 would need an additional Lambda function, for other server environments we might need to publish the config in a different format. Contact us for more information about this topic.
Sync to AWS S3
The most common method is using a FTP/SFTP to sync data to your server. We are also able to push the content into a S3 bucket. When using the static HTML version this would work out of the box. When you need URL rewrites / redirect it is possible in combination with a AWS Lambda function.
This option might need some extra help. Contact us for questions or requirements in combination with other storage options.
Putting content offline
When creating a project you are first able to test and preview the content through a local Maglr domain (customer.maglr.com). As soon as the project is ready and you hit the publish button assets will be synchronized to your corporate server.
You can make changes in between but also put a project offline. We move the content so it's not publicly available anymore.
Required diskspace
The amount of space you would need depends on the type of publication. A lot of assets or maybe videos require more space. In global a publication with around 10 pages would require +/- 50MB.
The data traffic depends on the amount is visitors. Since all content is static it's easy to serve it to bigger numbers in combination with a CDN.
Adding your own security layer
When the content is running on your server you are able to add custom security integrations (corporate employee login for example). As the Maglr content is static and does not require additioneel server components lot's of options are available.
Making the connection
When we push content to your storage server we need to configure the correct credentials. Because Maglr is hosted AWS, in a 'floating' Cloud set-up, we do not have a static IP. For this reason it's not possible to add our servers in a firewall configuration.
Information we need for each different connection type:
FTP: the most basic method requires a username + password.
SFTP: we provide a 'Public key' you can configure on your server. When configured we need a username with a (optional) password.
AWS S3: pushing content directly to a S3 requires a configured bucket. To connect to a bucket we need the region, key, secret-key and name of the bucket.
Note: this option is only available with the Maglr Enterprise license. This option requires a one-time set-up, depending of the type of synchronisation and IT requirements.
Updated on: 08/02/2023