This article builds an AWS SigV4 signer in pure MQL5 and wraps it in a small S3 client for PutObject, GetObject, and ListObjectsV2. It explains canonicalization, HMAC‑SHA256, and key derivation, and shows how to handle empty‑payload hashing and GMT timestamps to avoid SignatureDoesNotMatch. A script uploads a model and a CSV, downloads them back, and compares SHA‑256 checksums, providing a practical, DLL‑free path to centralized artifact storage.
Most MetaTrader 5 setups that use machine learning end up with the same unglamorous problem sooner or later: the model lives on whichever machine trained it. Retrain on a dev box, deploy on a VPS, and now there are two copies to keep in sync. Add a second VPS for a different symbol or a different broker, and it turns into a manual file-copying exercise nobody wants to own. Feature snapshots exported for offline analysis have the same issue in reverse - they need to get off the terminal and somewhere centralized before anyone can actually use them.
Amazon S3 is the obvious place to put both. It is cheap, versionable, and reachable from anywhere, and every language has an SDK for it - except MQL5. MetaTrader has no AWS library, and S3 will not accept an unsigned request: every call has to carry an AWS Signature Version 4 (SigV4) signature, a specific HMAC-based scheme that authenticates the request without ever putting the secret key on the wire. Building that signer natively means working entirely from what MQL5 actually exposes - CryptEncode() for hashing and WebRequest() for the HTTPS call - with no shortcut and no existing MQL5 implementation to borrow from.
The alternative to building this natively would be an external DLL wrapping a real AWS SDK, but that closes off the EA or script to anyone running MetaTrader 5 in a sandboxed or DLL-restricted environment - a real constraint on a lot of VPS and prop-firm setups. A native signer removes that specific restriction: it compiles without needing DLL imports enabled, at the cost of having to implement HMAC and the canonical-request construction by hand instead of calling into a maintained library. It still depends on WebRequest()'s own allow-list, and on whatever network/TLS policy the terminal or VPS enforces - going native removes the DLL requirement, not every environment constraint.
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
Check out the new article: Native AWS S3 Integration in MQL5: A Signature V4 Client for Model and Feature Artifact Storage.
Most MetaTrader 5 setups that use machine learning end up with the same unglamorous problem sooner or later: the model lives on whichever machine trained it. Retrain on a dev box, deploy on a VPS, and now there are two copies to keep in sync. Add a second VPS for a different symbol or a different broker, and it turns into a manual file-copying exercise nobody wants to own. Feature snapshots exported for offline analysis have the same issue in reverse - they need to get off the terminal and somewhere centralized before anyone can actually use them.
Amazon S3 is the obvious place to put both. It is cheap, versionable, and reachable from anywhere, and every language has an SDK for it - except MQL5. MetaTrader has no AWS library, and S3 will not accept an unsigned request: every call has to carry an AWS Signature Version 4 (SigV4) signature, a specific HMAC-based scheme that authenticates the request without ever putting the secret key on the wire. Building that signer natively means working entirely from what MQL5 actually exposes - CryptEncode() for hashing and WebRequest() for the HTTPS call - with no shortcut and no existing MQL5 implementation to borrow from.
The alternative to building this natively would be an external DLL wrapping a real AWS SDK, but that closes off the EA or script to anyone running MetaTrader 5 in a sandboxed or DLL-restricted environment - a real constraint on a lot of VPS and prop-firm setups. A native signer removes that specific restriction: it compiles without needing DLL imports enabled, at the cost of having to implement HMAC and the canonical-request construction by hand instead of calling into a maintained library. It still depends on WebRequest()'s own allow-list, and on whatever network/TLS policy the terminal or VPS enforces - going native removes the DLL requirement, not every environment constraint.
Author: Adesewa Tolulope Gbadebo