Quote from: kobik on February 14, 2018, 10:58:15 AM

I never thought about the seed being tied to my server. I thought a backup command was available so I can copy/backup the wallets to a safe place.

You can backup the seed of course, but you're sending it over a socket and it's sitting in your online machine as well. That's an attack surface you should be trying to reduce, not the other way around.

Quote

All the management will be done via a web-service (in our intranet only) talking to the bitcoind via RPC. e.g. opening new wallets; query of balance; send/receive funds; etc... I will be responsible for a web GUI talking to that web-service (talking to whatever full node via RPC).

You can run 1 DB and let your users have access to their wallet in GUIs each. The DB also has its own language over the socket, which goes over the FCGI protocol, ie from your end you can display balance and history with HTML/js straight from the DB if you'd like to go down that route. The RPC is fine too.

Quote

I toght Armory will let me do that bridge to the bitcoind, but the wallet managements will be done in Armory instead of bitcoind Wallets.

It does that but you need to elaborate on your requirements and opsec. How many addresses do you expect to use per employee? If it's only 1, just use lockboxes. Do you intent to give your employees signing privileges? If no, then only load watching only wallets in armoryd. It can create unsigned transactions that you can review and sign with an offline GUI/armoryd instance that has the full wallets loaded.

At any rate you are better off just letting armoryd run on watching only wallets and let people sign offline through the GUI, whether it's you or your employees. This model suggests you create the wallets offline and only import the public seed in armoryd.

So the question remains, do you actually need to create full wallets at all from the RPC? Chances are you don't, and shouldn't.