como poner mi app en la nube?

[Armando]

Foreros:

Pues eso, me gustaría subir mi app (EXE), hecha con FW y Harbour, utilizo la base de datos MySql y ADO.

Que necesito?, aparte de contratar un servidor, escucho sugerencias de servidores.

Alguien que ya tenga experiencia en el tema y quiera compartirla con un ñoño.

Saludos y agradecido con la info

[Otto]

viewtopic.php?p=278038&hilit=cloudflare#p278038

[Armando]

Mr. Otto:

Suena interesante, este cambio me lo esta pidiendo uno de mis clientes que ha tenido problemas de seguridad
(pérdida de datos) con su propio servidor.

Pienso proponerle pasar sus datos a la nube y atacarlos con mi aplicación hecha con FW y Harbour, reitero, uso
base de datos MySql.

Sería excelente si existiera un ambiente para pruebas para convencerlo.

Saludos y gracias por la atención

[Otto]

Estimado Sr. Armando:

¿Ha visto la guía? Es muy sencilla y creo que es más segura que un hosting. Nuestro foro también usa Cloudflare para protección; prácticamente todas las empresas de renombre lo usan, incluido ChatGPT.

En cuanto a las copias de seguridad, yo uso Windows Server Backup como copia principal y además una Synology y otra Synology como backup de la primera. También utilizo yepkit, que puede apagar la interfaz USB. Ya mostré esta solución aquí en el foro.
viewtopic.php?p=259584&hilit=yepkit#p259584
Ahora mismo estoy reorganizando y sistematizando de nuevo mi propio plan de copias. yepkit conmuta la interfaz USB diariamente —lo hago principalmente contra el ransomware—, además cambio físicamente los discos de vez en cuando y mantengo la copia en Synology con su backup. Creo que lo importante es tener al menos 2 copias en 2 ubicaciones distintas. Hoy mismo pedí otro juego de discos SSD USB para las copias.

En cuanto tenga el concepto por escrito lo publicaré. Pero el self-hosting es sin duda el futuro, al menos para nosotros aquí, porque cumplir con el Reglamento General de Protección de Datos (RGPD) es complicado de otra manera.

Un saludo y gracias.
Otto

[cmsoft]

Hola Armando:
Ejecutar desde la web una aplicacion Fivewin no se puede.
Lo que puedes hacer es mediante escritorio remoto, ejecutarla, pero no creo que sea lo mas aconsejable.
Tal vez no entendí bien tu idea, si es que el ejecutable quieres que se ejecute desde un sitio remoto, o que se descargue en la PC de tu cliente, y que la base de datos esté en la nube, o como dice el asunto, poner la app fivewin en la nube.
Usar la base de datos en la nube, eso si no es un problema para Fivewin, es totalmente posible.
Lo que si puedes hacer es alojar tu exe en un servidor y que el mismo programa se descargue y actualice cuando hay alguna modificacion (eso deberas controlarlo vos) mediante FTP.
No se si ayuda de mucho, pero es una idea

[Otto]

„¿Por qué te parece así? Yo pienso que, si no se hace una aplicación web, esta (RDP) es con mucho la mejor solución. ¿Cuáles son tus argumentos?“

[Armando]

Hola César:

Trataré de ser más explicito

En la actualidad tengo mi aplicación en un servidor LAN, las PC terminales están en red y se conectan al servidor
a través de un acceso directo, obviamente el EXE solo esta en el servidor, hasta ahí todo va de 100.

Mi idea, por cuestiones de seguridad de los datos, es que la base de datos (MySql) esté en la nube, las terminales
se sigan conectando al servidor local y que el exe se conecte a la nube, en lugar de LOCALHOST sea una dirección IP.

Saludos

[Otto]

I asked ChatGPT to briefly summarize my setup. By the way, one word looks exactly the same in English and Spanish: .

---

## Part 1 – Cloudflare Access and Tunnel Access Types

I myself use Cloudflare like this: **Cloudflare Access and Tunnel Access Types**
Armando, I’ll send it in English, otherwise I’m not sure the translation says exactly what I mean.

**Web access via Cloudflare (public website):**

* **Term:** Cloudflare Proxying / CDN-based website access
* **Characteristic:** The public website is delivered via Cloudflare. Traffic is optimized, cached, and protected, but without special authentication for end users.

**Web access via a Cloudflare Tunnel with token (for internal or protected applications):**

* **Term:** Cloudflare Access (token-based web access)
* **Characteristic:** Internal web applications or services are secured via tunnel. By retrieving a token in advance (`cloudflared access login`), access is controlled without exposing the applications directly to the Internet.

**RDP access via Cloudflare Tunnel (TCP forwarding via cloudflared):**

* **Term:** Cloudflare Access secured RDP tunnel
* **Characteristic:** RDP connections are routed through a Cloudflare Tunnel, which secures them. A local port is provided by `cloudflared access tcp` to use RDP internally without making it directly publicly accessible.

As you describe it, you’ve already clearly separated the three essential use cases of Cloudflare:

* **Public (Proxy/CDN):** Website, no authentication, everyone can access.
* **Web apps via Tunnel + Access login:** Internal tools, browser-based, with Zero Trust policies.
* **TCP services (RDP, SSH, MySQL, …) via cloudflared access tcp:** Secured, only for authorized users.

**Your current idea (“EXE + MySQL stay on the same server”):**

* **Good:** You don’t need to expose MySQL to the WAN.
* **Good:** Your EXE runs on the server with a localhost DB, everything ultra-fast.
* **User access:** Either via RDP through the tunnel or via a web interface through Tunnel/Access.

That prevents exactly what people argue against with a Cloudflare Tunnel: namely direct, latency-critical DB access from outside.

**Recommendation for your case:**

* Use Cloudflare Access + Tunnel for RDP → each user logs in via the browser (SSO/2FA), starts `cloudflared access tcp …`, and connects locally to `localhost:13389` → which maps to `server:3389`.
* Optional: If instead of full desktop you just want to provide the EXE → publish it as a RemoteApp (still via RDP Tunnel).
* Database stays local and secured (`bind-address=127.0.0.1`, no WAN ports).

**Advantages of this architecture:**

* No MySQL over the Internet → no latency issues, no risk, no unnecessary round-trips.
* Zero Trust layer in front → even if someone guesses your RDP port, they can’t get anywhere without an Access token.
* Centrally manageable → everything via the Cloudflare Dashboard (policies, logs, audit).

**Conclusion:**
There is no reason against using a Cloudflare Tunnel in your case – as long as you don’t tunnel MySQL itself externally, but the entire app session (RDP/RemoteApp). That’s exactly what Cloudflare Access + Tunnel is ideal for.

---

## Part 2 – Self-Hosting vs. External Hosting (KMU Perspective)

### Self-hosting (on-premise)

**Advantages:**

* **Full control:** Everything stays in your hands, no provider limits.
* **Speed:** Local access without any Internet detour.
* **Backup concept:** Your plan with Yepkit, disk rotation + Synology is stronger than standard hoster backups.
* **Flexibility:** Immediate changes possible at any time.
* **Cost control:** One-time hardware investment, then low running costs.
* **SIM failover:** LTE/5G backup on the router → Internet outages are bridged.
* **UPS for router & server infrastructure:** Covers power failures for up to a few hours. Servers, router, and Synology stay online even during short outages.
* **Maintenance at eye level:** With HP ProBooks as servers, you can procure replacement devices very cheaply and quickly. In case of failure, replacement takes hours, not days.

**Disadvantages:**

* **Large-scale power outage:** If the whole region goes down, even a UPS won’t help – then everyone is in the same boat.
* **Updates & monitoring:** All your responsibility. You decide when to patch – it’s work, but also security (you’re not dependent on the hoster).
* **Hardware repairs:** Your responsibility, but with the HP ProBook strategy often easier than with hosters (get replacement device → restore image/backup → system back up).

---

### Hosting with a provider

**Advantages:**

* **Redundancy:** Power, Internet, climate control are all multi-layered.
* **Monitoring & updates:** Taken care of for you (depending on the package).
* **Scalability:** Add resources within minutes.
* **Uptime guarantee:** Contractually guaranteed (SLA).

**Disadvantages (especially in SME context):**

* **Practical support:** As you said, in small and medium-sized businesses I’ve also never seen a hoster *really* help when it gets critical.
Example: If a VM freezes or databases misbehave, the answer is often “please reboot” or “that’s your software, not our problem.”
* **Costs:** Monthly fees add up.
* **Backups:** Usually rudimentary (once or twice daily, 7-day retention, often in the same datacenter).
* **Less flexibility:** Root or policy restrictions, vendor lock-in.

---

### Conclusion for SMEs

* With **HP ProBooks as servers + your backup concept + SIM failover + UPS**, you are in practice better protected than with 90% of standard hosting packages for hotels or SMEs.
* Hosters score points with redundancy in the datacenter – but in the event of a problem (e.g., faulty database, software crash, broken VM) you are still left on your own.
* Self-hosting means: You are responsible – but you also have **direct control** and can usually react much faster.
* And: In the mountains it’s true anyway → if there’s a regional power or Internet outage, even the fanciest datacenter won’t help. Then it’s just: **have a beer and wait. **

---
Le pedí a ChatGPT que resumiera brevemente mi configuración.

Parte 1 – Tipos de acceso con Cloudflare Access y Tunnel

Yo mismo uso Cloudflare de esta manera: Cloudflare Access y tipos de acceso con Tunnel.
Armando, te lo envío en inglés/español, de lo contrario no estoy seguro de que la traducción diga exactamente lo que quiero expresar.

Acceso web a través de Cloudflare (sitio web público):

Término: Cloudflare Proxying / acceso web basado en CDN

Característica: El sitio web público se entrega a través de Cloudflare. El tráfico se optimiza, se almacena en caché y se protege, pero sin autenticación especial para los usuarios finales.

Acceso web a través de un Cloudflare Tunnel con token (para aplicaciones internas o protegidas):

Término: Cloudflare Access (acceso web basado en token)

Característica: Las aplicaciones o servicios internos se aseguran mediante un túnel. Al obtener un token con antelación (cloudflared access login), el acceso se controla sin exponer directamente las aplicaciones a Internet.

Acceso RDP a través de Cloudflare Tunnel (reenviando TCP con cloudflared):

Término: Túnel RDP seguro con Cloudflare Access

Característica: Las conexiones RDP se enrutan a través de un túnel Cloudflare, que las protege. cloudflared access tcp proporciona un puerto local para usar RDP de forma interna sin hacerlo accesible públicamente.

Como lo describes, ya has separado claramente los tres casos de uso esenciales de Cloudflare:

Público (Proxy/CDN): Sitio web, sin autenticación, acceso libre.

Aplicaciones web vía Tunnel + Access login: Herramientas internas, en el navegador, con políticas Zero Trust.

Servicios TCP (RDP, SSH, MySQL, …) vía cloudflared access tcp: Asegurados, solo para usuarios autorizados.

Tu idea actual (“EXE + MySQL permanecen en el mismo servidor”):

Bueno: No necesitas exponer MySQL a la WAN.

Bueno: Tu EXE se ejecuta en el servidor con la BD en localhost, todo ultra-rápido.

Acceso de usuarios: O bien mediante RDP a través del túnel, o mediante una interfaz web por Tunnel/Access.

Eso evita exactamente lo que muchos critican de un Cloudflare Tunnel: el acceso directo desde fuera a una BD sensible a la latencia.

Recomendación para tu caso:

Usa Cloudflare Access + Tunnel para RDP → cada usuario inicia sesión vía navegador (SSO/2FA), arranca cloudflared access tcp …, y se conecta localmente a localhost:13389 → que apunta a server:3389.

Opcional: Si en vez del escritorio completo solo quieres ofrecer el EXE → publícalo como RemoteApp (también vía túnel RDP).

La base de datos permanece local y segura (bind-address=127.0.0.1, sin puertos WAN).

Ventajas de esta arquitectura:

Sin MySQL expuesto en Internet → sin problemas de latencia, sin riesgos, sin viajes innecesarios de ida y vuelta.

Capa Zero Trust delante → incluso si alguien adivinara tu puerto RDP, no podría llegar a nada sin un token de acceso.

Gestión centralizada → todo desde el panel de Cloudflare (políticas, logs, auditoría).

Conclusión:
No hay ninguna razón para no usar un Cloudflare Tunnel en tu caso, siempre que no expongas MySQL directamente, sino toda la sesión de la aplicación (RDP/RemoteApp). Para eso está pensado Cloudflare Access + Tunnel.

Parte 2 – Autoalojamiento vs. Hosting externo (perspectiva PYME)
Autoalojamiento (en tu propia infraestructura)

Ventajas:

Control total: Todo queda en tus manos, sin límites del proveedor.

Velocidad: Acceso local sin pasar por Internet.

Plan de copias de seguridad: Tu sistema con Yepkit, rotación de discos + Synology es más sólido que los backups estándar de los hosters.

Flexibilidad: Cambios inmediatos cuando los necesites.

Control de costes: Inversión única en hardware, luego costes bajos.

Failover con SIM: Respaldo LTE/5G en el router → se cubren caídas de Internet.

SAI (UPS) para router e infraestructura del servidor: Cubre cortes de energía de hasta unas horas. Los servidores, router y Synology permanecen en línea incluso en interrupciones cortas.

Mantenimiento a nivel práctico: Con HP ProBooks como servidores puedes conseguir reemplazos de forma muy barata y rápida. En caso de fallo, la sustitución tarda horas, no días.

Desventajas:

Apagón regional: Si toda la región se queda sin luz, ni el SAI ayuda – todos están en el mismo barco.

Actualizaciones y monitorización: Toda la responsabilidad es tuya. Decides cuándo aplicar parches – es trabajo, pero también seguridad.

Reparaciones de hardware: Dependen de ti, aunque con la estrategia de HP ProBooks muchas veces es más fácil que con un hoster (traer un repuesto → restaurar imagen/backup → volver a funcionar).

Hosting con un proveedor

Ventajas:

Redundancia: Energía, Internet y climatización con múltiples capas.

Monitorización y actualizaciones: Te las ofrecen según el paquete contratado.

Escalabilidad: Ampliar recursos en minutos.

Garantía de disponibilidad: Asegurada por contrato (SLA).

Desventajas (especialmente en PYMEs):

Soporte real: Como dices, en el ámbito de las pequeñas y medianas empresas tampoco he visto nunca que un hoster “ayude de verdad” en caso crítico.
Ejemplo: Si una VM se congela o la base de datos falla, la respuesta suele ser “reinicie por favor” o “ese es su software, no el nuestro”.

Costes: Las cuotas mensuales se acumulan.

Backups: Suelen ser rudimentarios (1–2 al día, retención de 7 días, a menudo en el mismo centro de datos).

Menos flexibilidad: Restricciones de root o políticas, dependencia del proveedor.

Conclusión para PYMEs

Con HP ProBooks como servidores + tu plan de copias de seguridad + failover SIM + SAI, en la práctica estás mejor protegido que con el 90 % de los paquetes estándar de hosting para hoteles o PYMEs.

Los hosters destacan en redundancia de centro de datos – pero en caso de problema (BD defectuosa, fallo de software, VM rota) el cliente sigue estando solo.

Autoalojamiento significa: eres responsable – pero también tienes control directo y puedes reaccionar mucho más rápido.

Y: En la montaña esto siempre se cumple → si hay un apagón regional o se corta Internet, ni el mejor centro de datos sirve. En ese momento solo queda: tomar una cerveza y esperar.

[cmsoft]

Hola César:

Trataré de ser más explicito

En la actualidad tengo mi aplicación en un servidor LAN, las PC terminales están en red y se conectan al servidor
a través de un acceso directo, obviamente el EXE solo esta en el servidor, hasta ahí todo va de 100.

Mi idea, por cuestiones de seguridad de los datos, es que la base de datos (MySql) esté en la nube, las terminales
se sigan conectando al servidor local y que el exe se conecte a la nube, en lugar de LOCALHOST sea una dirección IP.

Saludos

Excelente, eso es totalmente posible!
Simplemente levantas tu base de datos en la nuebe, y el programa tiene que hacer referencia a la IP o URL (Segun como lo definas) en lugar de localhost.

[Otto]

Hi César,

Thanks for your reply!
I just have one more question:

How exactly do you plan to secure access to the MySQL database in the cloud?

Would you open the MySQL port (3306) directly to the Internet?

Or do you plan to use VPN, SSH tunnel, Cloudflare Tunnel, or another Zero Trust solution?

The reason I ask is that an open MySQL port on the Internet is extremely insecure — bots are constantly scanning for it, and without additional protection the database could be compromised very quickly.

That’s why I’m curious to know what security strategy you have in mind here.

Best regards, Otto


I put the MySQL database in the cloud and access it via IP” — then you need to distinguish:

Simply opening the MySQL port (3306) → works technically right away, but it is highly dangerous (an open invitation for attacks).

Secure access (VPN, SSH tunnel, Cloudflare Tunnel, Zero Trust) → only works if the hosting provider or cloud provider also supports this technology.

That means:

With classic shared hosting or a simple DB-as-a-Service, you rarely have the option to install a VPN or tunnel → often the only options left are IP whitelisting and TLS.

With your own vServer or dedicated server, you can set up exactly these mechanisms yourself (OpenVPN, WireGuard, SSH, Cloudflare).

Cloudflare Tunnel requires a cloudflared agent installed on the host where the MySQL instance runs. If the hoster doesn’t allow that → it won’t work.

[jacgsoft]

Foreros:

Pues eso, me gustaría subir mi app (EXE), hecha con FW y Harbour, utilizo la base de datos MySql y ADO.

Que necesito?, aparte de contratar un servidor, escucho sugerencias de servidores.

Alguien que ya tenga experiencia en el tema y quiera compartirla con un ñoño.

Saludos y agradecido con la info

Lo que necesitas es:
- Dirección IP del servidor en la nube.
- Usuario y clave de la Base de datos en la nube.
- Nombre de la Base de datos en la nube.

Clase de conexión que uso actualmente para grabar en la NUBE, aunque igual funciona para modo LOCAL, lo único que variaria es la dirección IP:


// ********************************************************* //

CLASS TConexion_mysql
DATA oConexion
DATA cmySql_Usuario INIT 'USUARIO_BD'
DATA cmySql_Clave INIT 'CLAVE_BD'
DATA cmySql_Ip INIT '198.99.80.111'
DATA cmySql_BaseDatos INIT 'NOMBRE_BD'

METHOD New() INLINE Self CONSTRUCTOR

METHOD Conecta()

METHOD Close()

ENDCLASS

// ******************************************************* //

METHOD Conecta() CLASS TConexion_mysql
Local _Cadena_

_Cadena_:='Driver={MySQL ODBC 5.3 Unicode Driver}; Server='+::cmySql_Ip+';'+ ;
' Database='+::cmySql_BaseDatos+';User Id='+::cmySql_Usuario+ ;
';Password='+::cmySql_Clave+'; Option=3;'

::oConexion:=Toleauto():New("ADODB.Connection")
::oConexion:Open(_Cadena_)

Return(Self)

// ******************************************************* //

METHOD Close() CLASS TConexion_mysql

::oConexion:Close()

Return(Nil)

// ******************************************************* //

[Otto]

Security Risks
Hardcoded Credentials: The most significant vulnerability in the provided example is that the username and password are written directly into the code. An attacker who can access the compiled application (e.g., by decompiling it) could easily find and steal these credentials. This gives them direct access to your database.

Lack of Encryption: By default, data sent over an ODBC connection may not be encrypted. If the connection isn't configured to use SSL/TLS, an attacker on the same network could use a packet sniffer to capture the username, password, and all data being transmitted in plain text. This is a form of a "Man-in-the-Middle" attack.

SQL Injection: The ADODB.Connection object itself doesn't prevent SQL injection attacks. If you build SQL queries by concatenating user input directly into the query string, a malicious user can inject their own SQL code to read, modify, or delete data they shouldn't have access to. For example, a user could enter "test'; DROP TABLE users; -- " into an input field, which could delete your entire user table.

Network Exposure: The solution requires the application to connect directly to the database server's IP address on the public internet. This exposes the database to the entire internet, making it a target for brute-force attacks and other exploits. A hacker could try to guess the password, regardless of whether they have a copy of the application.

[Adolfo]

Hola César:

Trataré de ser más explicito

En la actualidad tengo mi aplicación en un servidor LAN, las PC terminales están en red y se conectan al servidor
a través de un acceso directo, obviamente el EXE solo esta en el servidor, hasta ahí todo va de 100.

Mi idea, por cuestiones de seguridad de los datos, es que la base de datos (MySql) esté en la nube, las terminales
se sigan conectando al servidor local y que el exe se conecte a la nube, en lugar de LOCALHOST sea una dirección IP.

Saludos

1000% se puede. Lo tengo asi con varios clientes, exe en el equipo local y MYSQL/MARIADB en la nube en algun hosting, el que sea.

Con FWH puede conectarte en una linea

FWCONNECT oSvr HOST "mipagina.cl" USER "cpedrum_xuser" PASSWORD "Ex876dFr-kIg+" DB "cpedrum_datos"

FWCONNECT oSvr HOST "200.72.1.5" USER "cpedrum_xuser" PASSWORD "Ex876dFr-kIg+" DB "cpedrum_datos" PORT 3303 (aca cambie el puerto si es que mi hosting permite responder por otro que no sea el 3306)

Yo utilizo un compresor de ejecutables para evitar la descompilacion del exe, UPX, funciona en consola y hace imposible descompilar mis exes, ademas que los reduce a casi el 30% de su tamaño, 100% probado y funciona tanto para exe's y para dll's (asi que comprimo las dos)

Tambien estoy preparando una prueba de conexion con seguidad SSl con la LIB de Cnavarro y apenas las termine pongo los resultados por aca.

No he tenido problemas de velocidad y utilizo todo el poder de SQL desde donde quiera, oficina principal y sucursales en otras ciudades.

[Otto]

Técnicamente se puede, pero hay varios puntos débiles que no conviene ignorar:

Superficie expuesta: Abrir el puerto de la BD en Internet es un riesgo enorme – cambiar el puerto no soluciona nada.

Credenciales distribuidas: Cada EXE lleva usuario y contraseña → alto riesgo si se pierde o copia.

Rendimiento y estabilidad: MySQL es muy “parlanchín”. En WAN aparecen latencias, bloqueos y cortes.

Cortes de conexión: Si se cae el túnel o la línea, la transacción se pierde.

Seguridad: Sin SSL/TLS y sin usuarios con mínimos privilegios la BD queda vulnerable.

Aspecto legal: Los datos viajan por redes externas – ojo con temas de privacidad/leyes (ej. RGPD).

Conclusión: Para pruebas puede servir, pero en producción es arriesgado. Mejor mantener EXE y BD en el mismo servidor y acceder desde fuera solo por RDP/RemoteApp vía Cloudflare Tunnel. Es más estable, seguro y fácil de mantener.

[Armando]

Adolfo:

Muchas gracias, por cierto, algún HOSTING para pruebas?

Saludos